Archiwa: Malware - Strona 231 z 235 - Security Bez Tabu

Tag: Malware

Silver Fox rozszerza ataki Winos 4.0 na Japonię i Malezję. Nowy łańcuch z HoldingHands RAT i zwinne obejście EDR

Wprowadzenie do problemu / definicja luki

18 października 2025 r. opisano nową fazę kampanii chińskojęzycznej grupy Silver Fox (znanej też jako SwimSnake, The Great Thief of Valley / Valley Thief, UTG-Q-1000, Void Arachne), która do tej pory intensywnie wykorzystywała framework Winos 4.0 (ValleyRAT). Najnowsze obserwacje pokazują rozszerzenie celów z Chin i Tajwanu na Japonię i Malezję, z wykorzystaniem HoldingHands RAT (Gh0stBins) dostarczanego przez wieloetapowe łańcuchy phishingowe oparte na PDF/ZIP/HTML. Atak kładzie nacisk na unikanie wykrycia i wyłączanie produktów bezpieczeństwa.

W skrócie

  • Wektor wejścia: e-maile phishingowe podszywające się pod ministerstwa finansów, faktury, rozporządzenia podatkowe (PDF z osadzonymi linkami → fałszywe strony pobierania → archiwa ZIP z loaderami).
  • Malware: Winos 4.0 / ValleyRAT oraz HoldingHands RAT (rodzina inspirowana Gh0st RAT).
  • Eskalacja i ukrywanie: m.in. BYOVD (wcześniejsza fala), sideloading DLL, łańcuch DLL/DAT wyzwalany przez Harmonogram zadań dla utrudnienia detekcji behawioralnej.
  • Nowość: możliwość zdalnej aktualizacji adresu C2 z poziomu rejestru (komenda 0x15), dojrzałe mechanizmy anty-VM i anty-AV (Norton/Avast/Kaspersky).
  • Zasięg geograficzny: Chiny → Tajwan → Japonia → Malezja (kampanie z I–X 2025).

Kontekst / historia / powiązania

Fortinet udokumentował styczniowe i lutowe 2025 ataki na Tajwan z Winos 4.0, następnie – w czerwcu – łańcuchy z HoldingHands i Gh0stCringe. We wrześniu potwierdzono falę SEO poisoning (fałszywe instalatory Chrome/Telegram/WPS/DeepL na stronach-klonach, wieloetapowe JSON-redirecty). Równolegle Check Point przypisał Silver Fox wykorzystanie podpisanego przez Microsoft podatnego sterownika WatchDog Anti-malware (amsdk.sys) w modelu BYOVD, do wyłączania EDR/AV i wdrażania ValleyRAT. Najnowszy wpis Fortinet z 17 października wiąże wszystkie te tropy, pokazując przejście kampanii na Japonie i Malezję.

Analiza techniczna / szczegóły luki

Łańcuch infekcji (wariant Malezja/Japonia, 2025-10):

  1. PDF/Word/HTML z odnośnikami (często do Tencent Cloud lub domen z prefiksem „tw*”) → strona pobrania w lokalnym języku (np. japoński) → ZIP z „audyt podatkowy” EXE.
  2. EXE ładuje złośliwy dokan2.dll (sideloading), który inicjuje sw.dat (loader z anty-VM, impersonacją TrustedInstaller, eskalacją uprawnień).
  3. sw.dat upuszcza w C:\Windows\System32\:
    svchost.ini (RVA VirtualAlloc), TimeBrokerClient.dll (przemianowany na BrokerClientCallback.dll), msvchost.dat (zaszyfrowany shellcode), system.dat (zaszyfrowany payload), opcj. wkscli.dll. Następnie zabija usługę Harmonogramu zadań, licząc na jej automatyczny restart po 1 minucie. Po restarcie svchost.exe wczytuje złośliwy TimeBrokerClient.dll – co utrudnia reguły behawioralne oparte na „uruchomieniu procesu przez użytkownika”.
  4. TimeBrokerClient.dll wylicza adres VirtualAlloc z svchost.ini, odszyfrowuje msvchost.dat, a z niego system.dat → końcowy HoldingHands ładowany w pamięci.
  5. Anty-AV: enumeracja procesów (Norton/Avast/Kaspersky) i próby ich ubicia; w razie wykrycia – modyfikacja przebiegu lub przerwanie działania.
  6. C2 i nowe komendy: heartbeat co 60 s, zrzuty ekranu/klawiatury, polecenia zdalne, dogrywanie modułów; aktualizacja adresu C2 przez rejestr HKCU\Software\HHClient\AdrrStrChar (komenda 0x15).

Starsze/alternatywne wektory Silver Fox (2025-05/09):

  • SEO poisoning + trojanizowane instalatory (EnumW.dll → vstdlib.dll → AIDE.dll; persistence przez skróty/COM hijacking), kradzież krypto, monitor ekranów.
  • BYOVD z podatnym, podpisanym sterownikiem WatchDog (amsdk.sys) – wyłączanie/terminowanie procesów AV/EDR na poziomie jądra, poza listą Microsoft Vulnerable Driver Blocklist w chwili odkrycia.

Praktyczne konsekwencje / ryzyko

  • Ucieczka przed EDR: wyzwalanie przez Harmonogram zadań po restarcie usługi sprawia, że nie widać „typowego” łańcucha procesów inicjowanego przez użytkownika.
  • Trwałość i sterowalność: zdalna zmiana C2 w rejestrze pozwala utrzymać dostęp mimo blokad sieci/infrastruktury.
  • Ryzyko sektorowe/regionalne: wysoka skuteczność socjotechniki w urzędach/finansach (tematy podatkowe), obecnie szczególnie Japonia i Malezja, wcześniej Tajwan i Chiny.

Rekomendacje operacyjne / co zrobić teraz

  1. E-mail & web: blokuj HTML/PDF z osadzonymi linkami w korespondencji finansowo-podatkowej; sandboxing plików ZIP/EXE; filtruj nowe/dziwne domeny z prefiksami „tw*”, hostingi chmurowe użyte w kampanii.
  2. EDR/telemetria: dodaj reguły na anomalię: restart usługi Schedule → natychmiastowe ładowanie TimeBrokerClient.dll przez svchost.exe, tworzenie plików svchost.ini / msvchost.dat / system.dat w System32. (Reguły behawioralne / Sigma/EDR custom).
  3. Rejestr & procesy: monitoruj klucz HKCU\Software\HHClient (wartość AdrrStrChar) oraz nietypowe instancje taskhostw.exe inicjowane przez CreateProcessAsUser z kontekstu svchost.exe –s Schedule.
  4. AV/EDR hardening: aktualizuj Microsoft Vulnerable Driver Blocklist i polityki blokowania sterowników; sprawdź obecność/ładowanie amsdk.sys (WatchDog) oraz artefaktów BYOVD wskazanych przez Check Point.
  5. Proxy/DNS/Netflow: alertuj na beacon 60 s do świeżych adresów C2; utrzymuj listy wskaźników z ostatnich raportów Fortinet/Seqrite.
  6. Edukacja użytkowników: kampanie uświadamiające wokół fałszywych pism ministerialnych i „audytów podatkowych”, w j. lokalnym (JP/MS).

Różnice / porównania z innymi przypadkami

  • Na tle klasycznych kampanii Gh0st-rodziny Silver Fox stosuje nietypowy trigger (restart usługi Schedule) oraz modułową aktualizację C2 z rejestru – to rzadziej spotykane w prostych klonach Gh0st RAT.
  • W porównaniu z wcześniejszą falą SEO-poisoning, obecne lury urzędowe (JP/MY) są bardziej ukierunkowane regionalnie i nie wymagają pozycjonowania wyszukiwarek.
  • BYOVD (WatchDog/Zemana) to technika na wyższym szczeblu uprzywilejowania niż typowe „userland” sideloadingi – pozwala agresywnie wyłączać ochronę przed dostarczeniem ValleyRAT/HoldingHands.

Podsumowanie / kluczowe wnioski

Silver Fox konsekwentnie iteruje taktyki: od phishingu podatkowego w Tajwanie (I–II 2025), przez SEO poisoning (VIII–IX 2025), aż po Japonie i Malezję (X 2025) z łańcuchem DLL/DAT wyzwalanym przez Harmonogram zadań i HoldingHands RAT jako finalnym payloadem. Nowo dodana aktualizacja C2 przez rejestr zwiększa odporność na blokady. Organizacje w regionie APAC (szczególnie finanse/administracja) powinny natychmiast wzmocnić kontrolę poczty, polityki sterowników oraz detekcje behawioralne wokół svchost.exe –s Schedule i artefaktów svchost.ini/msvchost.dat/system.dat.

Źródła / bibliografia

  • The Hacker News: „Silver Fox Expands Winos 4.0 Attacks to Japan and Malaysia via HoldingHands RAT” (18 października 2025). (The Hacker News)
  • Fortinet FortiGuard Labs: „Tracking Malware and Attack Expansion: A Hacker Group’s Journey across Asia” (17 października 2025). Główne źródło techniczne. (Fortinet)
  • Check Point Research: „Chasing the Silver Fox: Cat & Mouse in Kernel Shadows” – nadużycie sterownika WatchDog (BYOVD) (28 sierpnia 2025). (Check Point Research)
  • Seqrite Labs: „Operation Silk Lure: Scheduled Tasks Weaponized for DLL Side-Loading (drops ValleyRAT)” (ok. 16 października 2025). (Seqrite)
  • The Hacker News: „HiddenGh0st, Winos and kkRAT Exploit SEO, GitHub Pages in Chinese Malware Attacks” (15 września 2025). (The Hacker News)

Google Ads podszywają się pod Homebrew i LogMeIn. Kampania malvertising atakuje deweloperów macOS infostealerami (AMOS, Odyssey)

Wprowadzenie do problemu / definicja luki

Badacze odnotowali nową falę malvertisingu w Google Ads, w której przestępcy podszywają się pod Homebrew, LogMeIn i TradingView, aby infekować użytkowników macOS – głównie deweloperów – kradnącym dane malware: Atomic macOS Stealer (AMOS) oraz Odyssey Stealer. Reklamy prowadzą do witryn-klonów z instrukcjami uruchomienia komend w Terminalu (“ClickFix”), które pobierają i uruchamiają złośliwe skrypty, omijając mechanizmy ochronne (Gatekeeper).

W skrócie

  • Wektor wejścia: sponsorowane wyniki Google kierujące do fałszywych serwisów (np. homebrewonline[.]org, homebrewupdate[.]org, fałszywe domeny LogMeIn/TradingView).
  • TTP: socjotechnika ClickFix – ofiara kopiuje do schowka i uruchamia w Terminalu polecenie curl | bash ukryte pod pozornie nieszkodliwym przyciskiem “Copy/Verify”.
  • Ładunki: AMOS (MaaS, ~1000 USD/mies.) i Odyssey (fork Poseidon/AMOS) – kradzież haseł, cookies, Keychain, portfeli krypto, plików; exfiltracja do C2.
  • Skala: zidentyfikowano >85 powiązanych domen i współdzieloną infrastrukturę (m.in. IP 93.152.230[.]79, 195.82.147[.]38, certyfikaty SSL reuse).
  • Google: wcześniejsze fale malvertisingu Homebrew potwierdzano już na początku 2025 r.; Google deklarowało zawieszanie kont reklamodawców i usuwanie reklam naruszających zasady.

Kontekst / historia / powiązania

Fałszywe reklamy prowadzące do klonów Homebrew obserwowano już w styczniu 2025 r. – ad prezentował prawidłowy URL brew.sh, ale przekierowywał na niemal identyczne brewe.sh, skąd serwowano AMOS. Google usuwało reklamy i zawieszało powiązane konta, lecz technika powraca w nowych wariantach.
Latem 2025 r. rozwinęła się technika ClickFix (fałszywe “naprawy” i poradniki), którą BleepingComputer i CrowdStrike wiązali m.in. z rodziną Shamos (wariant AMOS). Obecna kampania recyklinguje tę samą logikę nakłaniania do uruchamiania komend.

Analiza techniczna / szczegóły luki

Socjotechnika i interfejsy stron:

  • Strony-klony wyświetlają instrukcję instalacji (Homebrew/LogMeIn/TradingView) oraz przycisk “Copy”. Kliknięcie wrzuca do schowka zaszyfrowaną Base64 komendę, która po wklejeniu do Terminala pobiera install.sh i uruchamia binarkę; stronę utrudniającą zaznaczanie tekstu i podgląd zawartości schowka opisano w raportach threat-intel.

Łańcuch infekcji:

  1. Wejście przez reklamę Google → domena phishingowa (np. homebrewfaq[.]org, tradingviewen[.]com, sites-phantom[.]com).
  2. “Copy” → Base64-curl → pobranie install.sh → pobranie ładunku (AMOS/Odyssey).
  3. Skrypt usuwa atrybut com.apple.quarantine (xattr) i nadaje prawa (chmod), co ominie Gatekeeper.
  4. Malware uruchamia kontrole anti-VM/sandbox, podnosi uprawnienia (sudo), zabija wybrane usługi (np. OneDrive updater), korzysta z XPC, zbiera artefakty systemowe i przeglądarkowe, a następnie exfiltruje dane do C2.

Infrastruktura i IOCs (wybór):

  • Domeny: homebrewonline[.]org, homebrewupdate[.]org, homebrewclubs[.]org, homebrewfaq[.]org, tradingviewen[.]com, tradingvieweu[.]com, sites-phantom[.]com, filmoraus[.]com; warianty LogMeIn: m.in. logmeln[.]com, logmeeine[.]com.
  • IP: 93.152.230[.]79, 195.82.147[.]38; korelacja po re-use certyfikatów SSL (np. CN związany z trading.example.com).

Rodziny malware:

  • AMOS – MaaS udostępniany na abonament (~1000 USD/mies.), eksfiltruje hasła, cookies, Keychain, portfele, karty; niedawno otrzymał komponent backdoora (persistent remote access).
  • Odyssey – nowa rodzina powiązana rodowodem z Poseidon/AMOS, kradnie dane z Safari/Chrome/Firefox, ponad setki rozszerzeń portfeli i Keychain, pakuje do ZIP i wysyła do C2.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości deweloperskiej (tokeny, SSH keys, cookies sesyjne) → ryzyko supply-chain (publikacja złośliwych buildów, backdoor w repo).
  • Utrata środków z kryptowalut/portfeli przeglądarkowych.
  • Persistent access (komponenty backdoor) i lateral movement w urządzeniach BYOD/MDM, także w kontekstach firmowych korzystających z LogMeIn/TradingView.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT:

  1. Nie uruchamiaj w Terminalu poleceń znalezionych na stronach innych niż oficjalne – prawidłowe domeny to m.in. brew.sh (Homebrew), nie ich warianty typograficzne. Dodaj reguły DNS/URL Filtering blokujące znane typosquaty (lista wyżej).
  2. Instalacja Homebrew: korzystaj z oficjalnej instrukcji na brew.sh (weryfikuj URL i certyfikat). Zawsze czytaj skrypty instalacyjne przed pipowaniem do shella.
  3. EDR/AV na macOS z detekcją stealerów (AMOS/Odyssey) i monitorowaniem uruchomień curl → bash oraz modyfikacji xattr. (Por. wcześniejsze raporty o kampaniach Homebrew/AMOS).
  4. Twarde polityki przeglądarki: wyłącz automatyczne uruchamianie skryptów z niezaufanych źródeł, izoluj profile przeglądarki, wymuś passkey/2FA dla krytycznych usług.
  5. Higiena kluczy i tokenów: rotacja Keychain, haseł, tokenów CI/CD i logowań do chmur po incydencie; unieważnienie sesji (cookies).
  6. Monitoruj IOC: dodaj do blokad i SIEM/EDR (domeny/IP powyżej), filtruj ruch do nowo-zarejestrowanych domen i TLD spoza profilu.

Dla zespołów marketingu/reklam:
7. Zgłaszaj podejrzane reklamy i nadużycia brandu w Google Ads; praktyka z pocz. 2025 r. pokazuje, że zawieszenia kont i usuwanie reklam są wdrażane, ale atakujący szybko rotują infrastrukturą – konieczny jest brand monitoring i taksonomie słów kluczowych (wykluczenia, “exact match”).

Dla SOC/DFIR – wskazówki detekcyjne (starter):

  • Sygnatury zachowania: łańcuch browser → clipboard → Terminal; procesy: Terminal.app/iTerm2 uruchamiają bash/zsh z parametrem -c oraz curl -fsSL ... | base64 -d | bash. Wzorce xattr -d com.apple.quarantine, chmod +x tuż przed uruchomieniem binarki.
  • Telemetria sieciowa: żądania do domen typosquattingowych (Homebrew/LogMeIn/TradingView), korelacja z IP 93.152.230[.]79 i 195.82.147[.]38 oraz reuse certyfikatów.

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

  • GitHub-malspam (AMOS): wcześniej dystrybucja przez fałszywe repozytoria; obecnie wraca malvertising + ClickFix. Wspólny mianownik: socjotechnika i kradzież tożsamości dewelopera.
  • “Fake fixes” na macOS (Shamos/AMOS): ta sama technika ClickFix, ale pretekst inny (rzekome naprawy systemu). Obecna kampania udaje instalatory znanych narzędzi (Homebrew/LogMeIn/TradingView).

Podsumowanie / kluczowe wnioski

  • Atak łączy SEO+Ads z socjotechniką Terminalową – skuteczny wobec deweloperów przyzwyczajonych do skryptowych instalatorów.
  • AMOS/Odyssey pozostają jednymi z najbardziej aktywnych stealerów na macOS; ich operatorzy recyklingują infrastrukturę i domeny, przez co kampanie są długowieczne.
  • Higiena instalacji (weryfikacja domen, brak “curl | bash” z niezweryfikowanych źródeł), telemetria EDR i blokady DNS to najszybsze środki obniżające ryzyko.

Źródła / bibliografia

  1. BleepingComputer – Google ads for fake Homebrew, LogMeIn sites push infostealers (18 października 2025). (BleepingComputer)
  2. Hunt.io – Odyssey Stealer & AMOS Hit macOS Developers with Fake Homebrew Sites (16 października 2025). (hunt.io)
  3. SecurityWeek – Homebrew macOS Users Targeted With Information Stealer Malware (23 stycznia 2025). (SecurityWeek)
  4. Bitdefender – Criminals Use Fake Mac Homebrew Google Ads in New Malicious Campaign (22 stycznia 2025). (Bitdefender)
  5. BleepingComputer – Fake Mac fixes trick users into installing new Shamos infostealer (22 sierpnia 2025). (BleepingComputer)

Korea Północna wykorzystuje „EtherHiding”: malware ukryty w smart kontraktach kradnie krypto i dane deweloperów

Wprowadzenie do problemu / definicja luki

16 października 2025 r. Google Threat Intelligence Group (GTIG/Mandiant) poinformował o pierwszym potwierdzonym użyciu techniki EtherHiding przez aktora państwowego – klaster przypisywany Korei Północnej (UNC5342). EtherHiding polega na osadzaniu złośliwego kodu w smart kontraktach na publicznych blockchainach (m.in. BNB Smart Chain, Ethereum) i wykorzystywaniu ich jak odpornego na wyłączenia „dead drop resolvera” do pobierania ładunków malware.

Technika wpisuje się w szerszą taktykę „dead drop resolver” opisaną w ATT&CK, gdzie legitymne usługi webowe przechowują wskaźniki do dalszej infrastruktury C2 lub payloadów, utrudniając blokowanie i atrybucję.

W skrócie

  • Kto: UNC5342 (aliasy m.in. DeceptiveDevelopment/DEV#POPPER/Famous Chollima).
  • Co: użycie EtherHiding do dostarczania wieloetapowego malware oraz kradzieży kryptowalut i poświadczeń.
  • Kiedy: kampania aktywna co najmniej od lutego 2025 r.; publiczne ujawnienie 16 października 2025 r.
  • Jak: socjotechnika na LinkedIn + przeniesienie rozmowy do Telegram/Discord; uruchamianie złośliwych zadań „testowych”.
  • Dlaczego to ważne: blockchain zapewnia odporność na Takedown, wersjonowanie payloadów i pseudonimowość wdrażających kontrakt.

Kontekst / historia / powiązania

Opisana aktywność łączy się z długotrwałą kampanią „Contagious Interview”, w której atakujący podszywają się pod rekruterów i celują w programistów/freelancerów. ESET od początku 2024 r. śledził zbliżony klaster „DeceptiveDevelopment”, dokumentując m.in. dążenie do kradzieży krypto-portfeli i danych z menedżerów haseł. To buduje ciągłość między wcześniejszymi operacjami a obecnym wykorzystaniem EtherHiding.

Równolegle media branżowe (np. CyberScoop) wskazują na rosnące użycie technik utrudniających wykrycie przez północnokoreańskie grupy – adopcja blockchaina jako elementu łańcucha dostarczania to kolejny krok tej ewolucji.

Analiza techniczna / szczegóły luki

Łańcuch infekcji (wysoki poziom):

  1. Lure & Initial Execution: ofiara (dev) wykonuje „zadanie rekrutacyjne” dostarczone po kontakcie przez LinkedIn → Telegram/Discord. Uruchamiany jest początkowy downloader, często w formie pakietu npm.
  2. BeaverTail (JS stealer): kradnie dane przeglądarki, rozszerzeń i portfeli, przygotowuje system pod kolejne etapy.
  3. JADESNOW (JS downloader): komponent, który komunikuje się z blockchainem (kontrakty na BSC/ETH) w trybie tylko-do-odczytu, by pobrać kolejny ładunek.
  4. InvisibleFerret (JS wariant backdoora): zapewnia zdalną kontrolę i długotrwałą eksfiltrację (m.in. MetaMask, Phantom, menedżery haseł). Na wybranych hostach doinstalowywany jest przenośny interpreter Pythona, aby uruchomić dodatkowe moduły kradnące.

Dlaczego blockchain? Smart kontrakt pełni rolę „bulletproof hostingu” dla wskaźników/payloadu: jest trudny do usunięcia, może być modyfikowany niskim kosztem (GTIG podaje średnie opłaty gazu rzędu ok. 1–2 USD na aktualizację), a odczyt danych z łańcucha nie zostawia śladów na dysku serwera atakującego.

Wieloplatformowość: kampania obejmuje Windows, macOS i Linux; do inicjalnej fazy wykorzystywane są artefakty deweloperskie (np. paczki npm), co zwiększa wiarygodność w oczach celu.

TTPs (wybrane):

  • T1102.001 Web Service: Dead Drop Resolver (odczyt z kontraktów/txn).
  • Pakiety ekosystemu JavaScript/npm jako nośnik initial stage.
  • Socjotechnika via LinkedIn → Telegram/Discord z pretekstem rekrutacji.

Praktyczne konsekwencje / ryzyko

  • Odporność na Takedown: klasyczne blokady domen/C2 niewystarczają – punktem dystrybucyjnym jest blockchain, nie pojedynczy serwer.
  • Aktywne wersjonowanie ładunków: aktor może szybko przestawiać wskaźniki i code-chunks w kontrakcie (niski koszt gazu), co utrudnia IOC-based hunting.
  • Docelowi użytkownicy o wysokich uprawnieniach: deweloperzy często dysponują tokenami, kluczami i dostępami do środowisk CI/CD, co podnosi ryzyko wtórnej kompromitacji łańcucha dostaw.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i hardening

  • Zasada „no task artifacts”: Zabroń uruchamiania binarek/skryptów dostarczonych w procesie rekrutacji. Wymagaj repo z powtarzalnym buildem i SBOM; uruchamiaj w izolacji (devcontainer/VM). (Wnioski na bazie ESET/GTIG).
  • Blokowanie dostępu do RPC publicznych (ETH/BSC) z hostów deweloperskich, o ile nie są potrzebne; ewentualnie proxy-allowlist dla konkretnych endpointów. (Wniosek analityczny na bazie TTP).
  • Policy na menedżery haseł i portfele: separacja profili przeglądarki, wymuszenie hardware-wallet dla środków firmowych.

Detekcja i monitoring

  • Use case „Blockchain as C2/DDR”: monitoruj nietypowe zapytania HTTP(s)/WebSocket do publicznych endpointów RPC (Infura, Ankr, Alchemy, publiczne BSC RPC) z hostów, które nie powinny rozmawiać z sieciami L1/L2. Koreluj z uruchomieniem node/py interpretera. (Mapowanie do T1102.001).
  • Hunting w przeglądarce: zdarzenia dot. rozszerzeń portfeli (MetaMask/Phantom), anomalia w plikach Local Storage/IndexedDB; detekcje na exfil JS-stealerów (BeaverTail).
  • Npm supply chain: alerty na instalację/uruchomienie niezweryfikowanych paczek lub niespodziewanych post-install scripts.

IR/Response

  • Odcinaj dostęp do providerów RPC na czas triage; zrzut pamięci przeglądarki i artefaktów rozszerzeń; rotacja kluczy API/CI i sekretów z menedżerów. (Wniosek operacyjny spójny z TTP opisywanymi przez GTIG/ESET).

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

„EtherHiding” nie jest całkowicie nową koncepcją – w przeszłości przestępcy nadużywali smart kontraktów do ukrywania JS dla kampanii np. na WordPress – ale po raz pierwszy potwierdzono adopcję tej metody przez aktor państwowy (DPRK). To istotny skok jakościowy względem wcześniejszych kampanii wykorzystujących tradycyjny hosting, paste-serwisy czy social media jako „dead drop”.

Podsumowanie / kluczowe wnioski

  • EtherHiding w wykonaniu UNC5342 pokazuje, że blockchain stał się elementem łańcucha dostarczania APT – nie tylko celem kradzieży krypto.
  • Obrona wymaga policy-driven ograniczenia dostępu do RPC, sandboxingu zadań rekrutacyjnych i behawioralnych detekcji na interakcje z łańcuchem bloków.
  • Zespoły powinny zaktualizować model zagrożeń o scenariusze „Blockchain as C2/DDR” i przygotować playbooki IR pod kradzież portfeli/przeglądarki.

Źródła / bibliografia

  1. Google Threat Intelligence (Mandiant): „DPRK adopts EtherHiding to deliver malware and steal cryptocurrency” – 16.10.2025. (Google Cloud)
  2. The Hacker News: „North Korean Hackers Use EtherHiding to Hide Malware Inside Blockchain Smart Contracts” – 16.10.2025. (The Hacker News)
  3. ESET WeLiveSecurity: „DeceptiveDevelopment targets freelance developers…” – 20.02.2025. (We Live Security)
  4. MITRE ATT&CK T1102.001 – Web Service: Dead Drop Resolver. (MITRE ATT&CK)
  5. CyberScoop: „North Korean operatives spotted using evasive techniques…” – 16.10.2025. (CyberScoop)

Microsoft unieważnia ponad 200 certyfikatów, by zablokować kampanię Rhysida — co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Microsoft poinformował, że w początku października 2025 r. zakłócił kampanię prowadzącą do wdrożeń ransomware Rhysida, unieważniając ponad 200 certyfikatów używanych do podpisywania złośliwych plików. Kampanię przypisano grupie Vanilla Tempest (znanej także jako Vice Spider / Vice Society). Złośliwe binaria podpisywano m.in. przy użyciu Trusted Signing oraz usług podpisywania kodu dostawców SSL.com, DigiCert i GlobalSign.

W skrócie

  • Vektor wejścia: fałszywe strony podszywające się pod witrynę pobierania Microsoft Teams (np. teams-download[.]buzz, teams-install[.]run, teams-install[.]top).
  • Payload: podpisany backdoor Oyster (znany też jako Broomstick/CleanUpLoader), wykorzystywany następnie do wdrożenia Rhysida.
  • Działanie obronne: Microsoft unieważnił >200 certyfikatów, aktualizując detekcje dla fałszywych podpisów oraz narzędzi kampanii.
  • Aktor: Vanilla Tempest — finansowo motywowany, znany z ataków na edukację i ochronę zdrowia, wcześniej wykorzystywał różne rodzinny ransomware (m.in. BlackCat, Quantum Locker, Zeppelin).

Kontekst / historia / powiązania

Vanilla Tempest to nowa nazwa taksonomiczna Microsoftu dla wcześniej trackowanego DEV-0832/Vice Society, znanego z ataków oportunistycznych i eklektycznego doboru ładunków szyfrujących.
Rhysida funkcjonuje w modelu RaaS i jest regularnym celem ostrzeżeń rządowych — najnowsza, zaktualizowana w 2025 r. notyfikacja CISA opisuje TTPs i IOC tej rodziny.
Backdoor Oyster był już wcześniej dystrybuowany przez malvertising/SEO-poisoning jako trojanizowane instalatory popularnych narzędzi (PuTTY, WinSCP, a ostatnio — Teams).

Analiza techniczna / szczegóły luki

Łańcuch ataku:

  1. Pozycjonowanie i reklamy kierowały ofiary na domeny łudząco podobne do legitymnych stron Teams.
  2. Pobierany plik MSTeamsSetup.exe był loaderem, który uruchamiał podpisaną wersję backdoora Oyster.
  3. Oyster zapewnia trwały, zdalny dostęp (kradzież plików, wykonywanie poleceń, dogrywanie ładunków), ułatwiając lateral movement i wdrożenie Rhysida.

Nadużycie zaufania:
Aktor wykorzystywał Trusted Signing (krótkoterminowe certyfikaty) oraz usługi podpisywania kodu SSL.com, DigiCert, GlobalSign, aby nadać artefaktom pozory wiarygodności (SmartScreen, AV/EDR trust). Microsoft przerwał kampanię przez hurtową revokację >200 certyfikatów powiązanych z fałszywymi instalatorami i narzędziami post-exploitation.

Praktyczne konsekwencje / ryzyko

  • Podpis ≠ bezpieczeństwo: Sam fakt podpisania binarium nie gwarantuje braku złośliwości. SOC-e powinny korelować podpisy z telemetrią uruchomień, siecią i zachowaniem.
  • Ryzyko supply-chain w userlandzie: Użytkownicy częściej „googlują” instalatory niż pobierają je z portali producenta — atak świetnie skaluje się na helpdeskach i w SMB.
  • Utrzymujące się TTPs: Nawet po revokacji certyfikatów aktor może się przegrupować z nowymi certyfikatami/infrastrukturą.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady domen/URL: natychmiast dodać do denylist znane domeny kampanii (teams-download[.]buzz, teams-install[.]run, teams-install[.]top, itp.) i monitorować pokrewne typosquaty.
  2. Źródła instalatorów: enforce’ować politykę pobierania oprogramowania wyłącznie z domen producenta; rozważyć blokadę pobrań EXE/MSI z wyszukiwarek.
  3. Kontrole podpisów: w EDR/SIEM budować reguły na anomalia podpisów (wydawca ≠ oczekiwany; chain do niedawno odwołanego certyfikatu; short-lived certs).
  4. Detekcje Oyster/Rhysida: wdrożyć najnowsze IOC/TTP z biuletynów branżowych i CISA; szukać nietypowych połączeń C2 oraz artefaktów loadera.
  5. Hardening przeglądarek/DNS: izolacja przeglądarek dla pobrań, DNS sinkhole dla domen malvertisingowych, blokada reklam na poziomie sieci.
  6. Edukacja użytkowników: krótkie runbooki „Jak bezpiecznie pobierać Teams” + banery w intranecie. (Źródła kampanii dowodzą skuteczności SEO-poisoningu).
  7. IR gotowość: playbook Ryusida/Oyster: containment hostów z podejrzanym MSTeamsSetup.exe, natychmiastowa rotacja poświadczeń, review logonów interaktywnych, hunting po sygnaturach podpisu.

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

W przeszłości widzieliśmy kradzione lub wyłudzone certyfikaty używane do podpisywania malware. Nowością jest systemowe nadużycie usług podpisywania (w tym Trusted Signing z krótką ważnością certyfikatów), co znacząco zwiększa tempo rotacji certyfikatów po stronie aktora i utrudnia proste bloki „na wydawcę”. Dzisiejsze zdarzenie pokazuje, że hurtowa revokacja i telemetria behawioralna są skuteczniejsze niż poleganie na samym zaufaniu do łańcucha certyfikacji.

Podsumowanie / kluczowe wnioski

  • >200 odwołanych certyfikatów to zdecydowany ruch, który obniża skuteczność kampanii, ale nie eliminuje ryzyka rearmowania się przeciwnika.
  • Fałszywe instalatory Teams + Oyster → Rhysida: łańcuch ataku był wiarygodny dzięki podpisom i SEO-poisoning.
  • Organizacje powinny wzmocnić kontrolę źródeł oprogramowania, reguły detekcji podpisów i higienę przeglądarkową.

Źródła / bibliografia

  1. SecurityWeek — „Microsoft Revokes Over 200 Certificates to Disrupt Ransomware Campaign”, 16 października 2025 r. (SecurityWeek)
  2. BleepingComputer — „Microsoft disrupts ransomware attacks targeting Teams users”, 16 października 2025 r. (BleepingComputer)
  3. CISA — „#StopRansomware: Rhysida Ransomware” (zaktualizowane 30 kwietnia 2025 r.). (CISA)
  4. Microsoft Security Blog — „DEV-0832 (Vice Society)…” (mapowanie do Vanilla Tempest), 25 października 2022 r. (Microsoft)
  5. Broadcom / Symantec — „Oyster backdoor spread via malicious Teams setup”, 29 września 2025 r. (Broadcom)

Korea Płn. ukrywa malware w blockchainie: jak działa EtherHiding i co to oznacza dla obrony?

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence (Mandiant) potwierdziło, że aktor państwowy z Korei Północnej (UNC5342) zaczął wykorzystywać publiczne blockchainy (Ethereum, BNB Smart Chain) do ukrywania i dostarczania złośliwego kodu. Technika znana jako EtherHiding osadza ładunki w smart kontraktach, co utrudnia blokowanie i „takedown” — kod pozostaje dostępny tak długo, jak działa sam blockchain. To pierwszy znany przypadek adopcji tej metody przez aktora państwowego.

O odkryciu poinformował również serwis The Record (Recorded Future News), który podkreśla, że kampania łączy socjotechnikę na deweloperach z loaderem JADESNOW i backdoorem INVISIBLEFERRET używanym w kradzieżach krypto.

W skrócie

  • Co nowego? Korea Płn. przenosi delivery/C2 do smart kontraktów (Ethereum/BSC), korzystając z bezpłatnych zapytań eth_call do pobierania ładunków bez śladów on-chain (brak opłat/gazu).
  • Po co? Decentralizacja = odporność na zdejmowanie infrastruktury i listy blokujące; możliwość zdalnych, cichych aktualizacji łańcucha infekcji.
  • Jakie malware? Loader JADESNOW → wariant JS INVISIBLEFERRET (oraz inne moduły), wcześniej obserwowane w kradzieżach kryptowalut.
  • Kogo celują? Deweloperzy (krypto/tech), rekrutacje „Contagious Interview” i zadania techniczne z trojanizowanymi paczkami npm/VSC.

Kontekst / historia / powiązania

EtherHiding nie jest całkiem nowe: po raz pierwszy opisano je w 2023 r. jako element kampanii CLEARFAKE, która podszywała się pod aktualizacje przeglądarki i osadzała JS w kontraktach BSC. Wówczas była to taktyka finansowo motywowanego UNC5142; dziś po raz pierwszy adoptuje ją aktor państwowy (UNC5342).

Dopełnieniem tła są długotrwałe kampanie DPRK na rynku krypto (fałszywi rekruterzy, pakiety npm, drenaż portfeli). Unit 42 opisało je jako Contagious Interview – podszywanie pod headhunterów, zadania techniczne, łańcuchy z loaderami i backdoorami.

Równolegle Cisco Talos dokumentuje ewolucję narzędzi powiązanych z DPRK (np. BeaverTail, OtterCookie) oraz częste instalowanie INVISIBLEFERRET w podobnych klastrach aktywności. To spójne z obserwacjami Google dot. kampanii na deweloperów.

Analiza techniczna / szczegóły luki

Łańcuch ataku (wysoki poziom):

  1. Initial access: socjotechnika (LinkedIn/komunikatory), fikcyjne firmy, „zadanie rekrutacyjne” → pobranie paczki z npm/GitHub.
  2. Loader: niewielki skrypt JS (JADESNOW) wstrzykiwany do projektu/środowiska.
  3. On-chain fetch: skrypt wykonuje zapytania read-only (np. eth_call) do smart kontraktu w Ethereum/BSC, odczytując zaszyfrowane (Base64 + XOR) dane wejściowe z przechowywanych zmiennych/zdarzeń. Brak transakcji = brak śladu on-chain + brak opłat.
  4. Dekodowanie/egzekucja: odszyfrowany JS uruchamia JADESNOW → dostarcza INVISIBLEFERRET (JS/Python), opcjonalnie doładowuje infostealery; payload bywa przełączany między łańcuchami (Ethereum ↔ BSC) dla utrudnienia analizy i optymalizacji kosztów gazu.

Dlaczego to działa?

  • Decentralizacja i niezmienność utrudniają zrywanie łańcucha C2/delivery (brak „serwera” do przejęcia), a autor kontraktu może aktualizować dane/pola zgodnie z ABI i w okamgnieniu zmieniać konfigurację kampanii.
  • Warstwa dostępu: mimo że kontrakt jest permissionless, operatorzy często korzystają z centralizowanych usług API (np. dostawcy endpointów), które stanowią jedyny punkt obserwacji/zakłócenia dla obrońców.

Pochodzenie techniki: Guardio Labs opisało EtherHiding w 2023 r. w kontekście CLEARFAKE (kompromitowane strony WordPress, fałszywe aktualizacje, ładunki JS w BSC), co stanowiło „bulletproof hosting 2.0”.

Praktyczne konsekwencje / ryzyko

  • Takedown-resistance: klasyczne playbooki (sinkhole, hosting takedown, blokada domen) są mało skuteczne – kod żyje w łańcuchu. Blue team musi celować w punkty pośrednie: dostawców RPC/API, reguły sieciowe, łańcuchy deszyfracji.
  • Low-noise delivery: eth_call nie tworzy transakcji, więc logika ładowania jest „cicha” – brak detekcji opartej na anomaliach transakcyjnych.
  • Supply-chain & dev tooling: wektor przez npm/VS Code/IDE zwiększa ryzyko dla zespołów R&D i CI/CD; paralela do kampanii opisywanych przez Unit 42 i Talos.

Rekomendacje operacyjne / co zrobić teraz

Detection & telemetry

  • Egress/DNS/HTTP(S): profiluj i blokuj nietypowe połączenia do publicznych API blockchain (np. etherscan.io, bscscan.com, komercyjni providerzy RPC), jeśli hosty nie są potrzebne biznesowo. Twórz wyjątki per zespół krypto.
  • Content inspection: YARA/Detections na artefakty JADESNOW/INVISIBLEFERRET oraz sekwencje Base64+XOR w JS; hunting na wywołania Web3 (eth_call, eth_getLogs) z kontekstu przeglądarki/Node.
  • IDE & package security: enforce’uj blokady pobierania paczek npm z niezatwierdzonych źródeł; skanery SCA/typosquatting; monitoruj podejrzane rozszerzenia VS Code. (Zbieżne z obserwacjami Talos i Unit 42).

Hardening & procesy

  • Separacja środowisk dev: kontenery/VM z ograniczeniami sieciowymi; brak dostępu do kluczy produkcyjnych i walletów z maszyn deweloperskich.
  • Polityka RPC: jeżeli Web3 jest wymagane, kieruj ruch przez własne bramki/proxy z inspekcją i listą dozwolonych adresów kontraktów.
  • AppSec: CSP/Trusted Types, blokowanie wstrzyknięć JS na stronach WWW, ochrona WordPress (CLEARFAKE wciąż infekuje serwisy).
  • Szkolenia & Playbooks: tabletop wokół „fałszywej rekrutacji”, weryfikacja zadań technicznych, zasada „no binary from chat/IM”, procedury IR dla łańcuchów Web3.

IOC/Threat intel

  • Wykorzystaj wskazane przez Google adresy kontraktów/artefakty (np. przykładowy adres BSC z analizy) do budowy reguł blocklist i TI – pamiętając, że atakujący mogą szybko zmieniać wartości on-chain.

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

  • CLEARFAKE (UNC5142, 2023–): motywacja finansowa, infekcje WordPress i fałszywe aktualizacje przeglądarki; EtherHiding było tam nośnikiem infostealerów. UNC5342 (2025): adopcja przez aktora państwowego, wektor rekrutacyjny na devów, łańcuch z JADESNOW → INVISIBLEFERRET i kradzieże krypto.
  • BeaverTail/OtterCookie (Talos): inny klaster DPRK ukierunkowany na deweloperów; wspólne TTP (fałszywe oferty pracy, npm), ale niekoniecznie używa EtherHiding. Pokazuje jednak szeroką dywersyfikację narzędzi DPRK.

Podsumowanie / kluczowe wnioski

EtherHiding przenosi delivery/C2 do warstwy, której nie można „wyłączyć”. Wejście aktora państwowego do gry (UNC5342) przyspieszy adopcję tej techniki w APT i cyberprzestępczości. Obrona musi przestawić się na kontrolę dostępu do providerów RPC/API, hunting artefaktów Web3 w JS i twarde procesy bezpieczeństwa w zespołach deweloperskich.

Źródła / bibliografia

  1. Google Cloud Blog (GTIG/Mandiant): DPRK Adopts EtherHiding: Nation-State Malware Hiding on Blockchains, 16.10.2025. (Google Cloud)
  2. The Record (Recorded Future News): North Korean hackers seen using blockchain to hide crypto-stealing malware, 16.10.2025. (The Record from Recorded Future)
  3. Guardio Labs: Hiding Web2 Malicious Code in Web3 Smart Contracts (EtherHiding), 13.10.2023. (Guardio)
  4. Palo Alto Networks Unit 42: Contagious Interview – DPRK Threat Actors Lure Tech Job Seekers as Fake Recruiters, 09.10.2024. (Unit 42)
  5. Cisco Talos: BeaverTail and OtterCookie evolve with a new JavaScript module, 16.10.2025. (Cisco Talos Blog)

Fałszywe alerty „wycieku” LastPass i Bitwarden kończą się przejęciem komputera. Jak działa kampania i jak się bronić

Wprowadzenie do problemu / definicja luki

Trwa kampania phishingowa podszywająca się pod LastPass i Bitwarden. Ofiary otrzymują e-maile informujące o rzekomym włamaniu i pilnej konieczności zainstalowania „bezpieczniejszej” wersji aplikacji desktopowej. Po kliknięciu linku i uruchomieniu pliku instalowany jest agent narzędzia RMM, a następnie ScreenConnect (zdalny pulpit), co umożliwia atakującemu pełne przejęcie stacji roboczej. To nie jest prawdziwy incydent po stronie LastPass/Bitwarden — to socjotechnika.

W skrócie

  • Temat: podszywanie się pod LastPass/Bitwarden z fałszywymi „alertami o włamaniu”.
  • Wejście: e-mail z domen typu lastpasspulse.blog, lastpasjournal.blog, bitwardenbroadcast.blog z linkiem do „nowej aplikacji desktopowej”.
  • Łańcuch infekcji: instalacja Syncro (RMM) → doinstalowanie ScreenConnect → zdalne przejęcie hosta, możliwość dołożenia malware i kradzieży danych.
  • Stan faktyczny: LastPass potwierdza, że nie doszło do włamania; wskazuje IoC (domeny, IP) i że strony są blokowane jako phishing.
  • Powiązane: tydzień wcześniej podobny schemat uderzał w użytkowników 1Password (phishing na „Watchtower”).

Kontekst / historia / powiązania

Napastnicy coraz częściej celują w menedżery haseł — zaufane marki zwiększają skuteczność socjotechniki, a przejęcie takiego konta daje dostęp do wielu usług. Oprócz obecnej fali na LastPass/Bitwarden, w październiku 2025 opisana została kampania podszywająca się pod 1Password (fałszywe alerty Watchtower, domena phishingowa i przekierowania przez Mandrill). Widzimy więc trend ataków „brand-impersonation” w obrębie tej kategorii narzędzi.

Analiza techniczna / szczegóły kampanii

Wejście (Initial Access):

  • E-maile o temacie w stylu „We Have Been Hacked – Update Your … Desktop App…”, nadawcy m.in. hello@lastpasspulse[.]blog, hello@lastpassgazette[.]blog, hello@lastpasjournal[.]blog oraz wariant dla Bitwarden (hello@bitwardenbroadcast[.]blog). Linki prowadzą do stron typu lastpassdesktop[.]com / lastpassgazette[.]blog.

Środowisko hostingu i blokady:

  • Domeny były osłaniane przez Cloudflare i oznaczane jako phishing; odnotowano wykorzystanie hostingu kojarzonego z „bulletproof” dostawcami.

Wykonanie (Execution) i triks techniczne:

  • Pobierany binarny „installer” nie jest aplikacją menedżera haseł. To agent Syncro (RMM) uruchamiany z parametrami ukrywającymi ikonę w trayu. Po zestawieniu łączności agent dociąga ScreenConnect (BYO installer), który daje atakującemu interaktywny zdalny dostęp. Konfiguracja ograniczona do minimum (check-in co 90 s), bez włączonego natywnego zdalnego dostępu w Syncro i bez dodatkowych integracji typu Splashtop/TeamViewer; skrypty wyłączają lub blokują agentów Emsisoft/Webroot/Bitdefender.

Cel (Impact):

  • Po ustanowieniu sesji RDP-like atakujący może: doinstalować infostealery/ransomware, eksfiltrację danych, przejąć przeglądarki/menedżery haseł (po odblokowaniu sesji użytkownika), pivotować w sieci.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy indywidualni: ryzyko kradzieży całej „skrzynki z kluczami” (vault), danych finansowych i tożsamości; potencjalne szyfrowanie danych.
  • Firmy/MSP: RMM jako „żywe z ziemi” (LOTL) utrudnia detekcję; możliwe obejście części EPP/AV; ekspozycja poświadczeń korporacyjnych i danych klientów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesków:

  1. Ignoruj i raportuj: nie instaluj „nowej aplikacji desktopowej” z linków e-mail; zgłaszaj do dostawcy (np. abuse@lastpass.com).
  2. Weryfikuj komunikaty wyłącznie w panelu/kanałach oficjalnych (blog, status, help). Firmy nie proszą o podanie master password w e-mailu.
  3. Sprawdź legalność wiadomości Bitwarden – oficjalne maile nie mają załączników i nie proszą o pobranie pliku.
  4. EDR/AV skan pełny i audyt uruchomionych usług: poszukaj Syncro/ScreenConnect; w razie znajdowania – izoluj host, resetuj hasła (zwłaszcza do menedżera haseł) i weryfikuj MFA.
  5. Ustaw reguły blokujące instalację i komunikację popularnych RMM (allow-list w firmach), segmentacja i zasada najmniejszych uprawnień na stacjach helpdesk.

Dla zespołów bezpieczeństwa/SOC:

  • Blokuj IoC z poniższej listy na bramkach i EDR; huntuj po DNS/HTTP/S, procesach i usługach (np. SyncroMSP, artefakty ScreenConnect).
  • User awareness: krótkie szkolenie o „fałszywych wyciekach” i wzorcach stylu (nagłówki, słownictwo, presja czasu, weekendowe wysyłki).

Wybrane IoC (na podstawie bieżących publikacji):

  • Nadawcy: hello@lastpasspulse[.]blog, hello@lastpassgazette[.]blog, hello@lastpasjournal[.]blog, hello@bitwardenbroadcast[.]blog.
  • Domeny/URL: lastpassdesktop[.]com, lastpassgazette[.]blog, potencjalnie lastpassdesktop[.]app.
  • Infrastruktura (wg LastPass w chwili publikacji): IP 172.67.147[.]36, 172.67.219[.]2, 84.32.84[.]32; nagłówkowe IP 148.222.54[.]15, 23.83.222[.]47. Uwaga: adresy mogą się zmieniać – utrzymuj bloki jako time-boxed.
  • Narzędzia po stronie ofiary: Syncro (RMM) → ScreenConnect (zdalny dostęp).

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

  • Obecna kampania (LastPass/Bitwarden): główny cel to przejęcie endpointu poprzez RMM i zdalny dostęp (ScreenConnect). Nie chodzi tylko o kradzież danych logowania z fałszywej strony, ale o pełną kontrolę nad hostem.
  • Kampania na 1Password (tydzień wcześniej): klasyczny credential phishing (np. link do fałszywej strony po przekierowaniu), bez instalacji RMM; wektor oparty o „Watchtower breach alert”.

Podsumowanie / kluczowe wnioski

  • Nie doszło do nowego włamania do LastPass ani Bitwarden — to fałszywe alerty.
  • Kliknięcie w link i instalacja „nowej aplikacji” kończy się instalacją RMM i zdalnym przejęciem komputera.
  • Trend: rośnie liczba kampanii podszywających się pod marki menedżerów haseł (LastPass, Bitwarden, 1Password). Weryfikuj komunikaty tylko w oficjalnych kanałach i egzekwuj polityki blokowania RMM.

Źródła / bibliografia

  • BleepingComputer: Fake LastPass, Bitwarden breach alerts lead to PC hijacks (analiza kampanii, łańcuch RMM → ScreenConnect). (BleepingComputer)
  • LastPass (oficjalny blog): October 13 Phishing Campaign Leveraging LastPass Branding — dementi, IoC (domeny, IP), wskazówki. (The LastPass Blog)
  • Malwarebytes: Phishers target 1Password users with convincing fake breach alert — kontekst i podobna kampania tydzień wcześniej. (Malwarebytes)
  • Bitwarden Help Center: Identify Legitimate Emails from Bitwarden — jak rozpoznać prawdziwe maile (brak załączników/plików). (Bitwarden)

Krytyczne ryzyko łańcucha dostaw w marketplace’ach rozszerzeń VS Code: co odkrył Wiz i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Zespół Wiz Research ujawnił 15 października 2025 r. systemowy problem bezpieczeństwa w ekosystemie rozszerzeń VS Code: setki kluczy i tokenów dostępowych zostały nieumyślnie spakowane w paczki rozszerzeń i opublikowane w Visual Studio Code Marketplace oraz Open VSX. W ponad stu przypadkach były to tokeny umożliwiające… aktualizację samego rozszerzenia — a ponieważ VS Code domyślnie autoaktualizuje rozszerzenia, przejęcie takiego tokenu pozwalałoby rozesłać złośliwą aktualizację do całej bazy instalacji danego rozszerzenia.

W skrócie

  • Wiz znalazł 550+ ważnych sekretów w 500+ rozszerzeniach od setek wydawców; w tym tokeny Azure DevOps (VS Marketplace) i Access Tokens Open VSX. Łącznie dotknięta baza instalacji to ponad 85 tys. (VS Marketplace) i 100 tys. (Open VSX).
  • Po zgłoszeniu przez Wiz, Microsoft włączył skanowanie sekretów i blokowanie publikacji rozszerzeń zawierających wykryte klucze; skanowanie objęło też istniejące rozszerzenia.
  • Open VSX wprowadził prefiks tokenu („ovsxp_”) ułatwiający wykrywanie wycieków przez narzędzia skanujące.

Kontekst / historia / powiązania

Ryzyko łańcucha dostaw w IDE narasta od lat: rozszerzenia mają dostęp do środowiska dewelopera i mogą wykonywać kod. Microsoft dokumentował mechanizmy kontroli i „trust” w runtime rozszerzeń, ale tajne klucze w paczkach to inny wektor — działa poza samym silnikiem uprawnień: atak następuje na etapie publikacji/aktualizacji. Dlatego Microsoft zapowiedział i wdrożył „Secret Detection for Extensions” w Marketplace, a dodatkowo opisał szerszy plan podniesienia zaufania do ekosystemu.

Analiza techniczna / szczegóły luki

Wiz rozpakowywał paczki .vsix (to zwykłe archiwa ZIP) i znajdował w nich m.in.:

  • Dotfiles i pliki konfiguracyjne (np. .env, config.json, mcp.json, .cursorrules) zawierające klucze;
  • Twardo zakodowane sekrety w kodzie/package.json/README;
  • Tokeny wydawców:
    • Azure DevOps PAT (dla publikacji do VS Marketplace),
    • Open VSX Access Tokens (dla Open VSX).

Najgroźniejsze były tokeny publikacyjne — przejęcie ich pozwalałoby wypchnąć złośliwą wersję do całej bazy odbiorców danego rozszerzenia (przy włączonym auto-update). Wiz potwierdził 100+ ważnych PAT-ów VS Marketplace (ok. 85 tys. instalacji) oraz 30+ tokenów Open VSX (ok. 100 tys. instalacji).

Praktyczne konsekwencje / ryzyko

  • Masowa dystrybucja malware przez zaufany kanał aktualizacji rozszerzeń.
  • Ukierunkowane ataki na firmy korzystające z wewnętrznych/„vendor-specific” rozszerzeń opublikowanych publicznie „dla wygody”.
  • „Fałszywe poczucie bezpieczeństwa” przy motywie/tematach (themes) — choć zwykle nie zawierają kodu, nic nie blokuje dołączenia złośliwych payloadów do takiej paczki.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów developerskich

  1. Minimalizacja rozszerzeń – instaluj tylko niezbędne; oceń reputację wydawcy, historię wersji i liczbę instalacji.
  2. Zarządzanie autoaktualizacją – rozważ kontrolowane okna aktualizacji i obserwację zmian uprawnień/rozmiaru paczki; w środowiskach korporacyjnych wdrażaj aktualizacje etapowo.
  3. Inwentaryzacja i „allowlista” rozszerzeń (VS Code wspiera centralne polityki).

Dla wydawców rozszerzeń

  1. CI gate na sekrety: uruchamiaj skanery sekretów (np. GitHub Advanced Secret Scanning/partner program) i blokuj build/publikację przy wykryciu.
  2. Higiena repo/paczki: usuń .env i inne dotfiles z artefaktów (.vscodeignore / konfiguracja vsce), rotuj i skracaj TTL dla tokenów.
  3. Migracja tokenów: używaj tokenów z identyfikowalną strukturą/prefiksem (np. ovsxp_ w Open VSX) – to zwiększa skuteczność ochrony.

Dla operatorów platform

  1. Blokowanie publikacji z sekretami (pre-publish scanning) i skan „retro” istniejących rozszerzeń. Microsoft ogłosił i włączył tryb blocking w VS Marketplace.
  2. Standardyzacja sekretów (prefiksy, checksumy, CASK) oraz krótkie TTL.
  3. Transparentność i roadmapa bezpieczeństwa — publikowanie postępów i zasad (jak w aktualizacji Microsoft z czerwca 2025).

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

Ta kampania nie polegała głównie na publikacji ewidentnie złośliwych rozszerzeń, ale na wyciekach sekretów wydawców, co czyni wektor wyjątkowo niebezpiecznym: atakujący może podszyć się pod legalnego wydawcę i wykorzystać auto-update. To odróżnia sprawę od „klasycznych” kampanii złośliwych pluginów, a reakcje platform (blokowanie publikacji, skan istniejących paczek, prefiksy tokenów) są tu kluczowe.

Podsumowanie / kluczowe wnioski

  • Łańcuch dostaw IDE to realny wektor ataku: sekret w paczce rozszerzenia = potencjał RCE przez zaufaną aktualizację.
  • Reakcja platform (blokowanie publikacji, retro-skan, prefiksy tokenów) znacząco zmniejsza ryzyko, ale higiena po stronie wydawców i zespołów pozostaje niezbędna.
  • Organizacje powinny wdrożyć allowlistę, inwentaryzację, kontrolowane aktualizacje oraz policyjne skanowanie sekretów w CI/CD.

Źródła / bibliografia

  1. Wiz Research: “Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (15 października 2025). (wiz.io)
  2. GitHub (Microsoft VS Marketplace): „Upcoming Security Enhancement: Secret Detection for Extensions” + ogłoszenie trybu blocking. (GitHub)
  3. Microsoft DevBlogs: „Security and Trust in Visual Studio Marketplace” (11 czerwca 2025). (Microsoft for Developers)
  4. Open VSX (Eclipse): dokumentacja prefiksu tokenów ovsx.token-prefix. (GitHub)
  5. VS Code Docs: „Extension runtime security” (sekcja o skanowaniu sekretów i blokowaniu publikacji). (Visual Studio Code)