Archiwa: Security News - Strona 290 z 297 - Security Bez Tabu

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 → JaponiaMalezja (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)

Nowy backdoor .NET „CAPI” atakuje rosyjską motoryzację i e-commerce przez ZIP-y z LNK

Wprowadzenie do problemu / definicja luki

Badacze z Seqrite Labs opisali nową kampanię wymierzoną w rosyjski sektor motoryzacyjny i e-commerce, wykorzystującą dotychczas nieudokumentowane złośliwe oprogramowanie .NET nazwane CAPI Backdoor. Dystrybucja odbywa się przez spreparowane wiadomości e-mail z archiwum ZIP zawierającym skrót LNK i przynętę PDF dotyczącą zmian w podatku dochodowym. Pierwsze artefakty kampanii pojawiły się w VirusTotal 3 października 2025 r.; szczegóły publicznie opisano 17–18 października 2025 r.

W skrócie

  • Wektor wejścia: spear-phishing z archiwum ZIP zawierającym LNK, który uruchamia DLL backdoora przez rundll32.exe (living-off-the-land).
  • Zdolności CAPI: kradzież danych z przeglądarek (Chrome/Edge/Firefox), zrzuty katalogów, screenshoty, rozpoznanie systemu, anty-VM, persystencja (Startup LNK + zaplanowane zadanie).
  • Infrastruktura: domena podszywająca się pod carprice[.]ru (carprlce[.]ru) oraz C2 91.223.75[.]96.
  • Mapowanie do MITRE ATT&CK: T1566.001 (Spearphishing Attachment), T1218.011 (Signed Binary Proxy Execution: rundll32), T1113 (Screen Capture), T1555.003 (Credentials from Web Browsers) itd.

Kontekst / historia / powiązania

Zastosowanie rundll32.exe jako LOLBin jest od lat popularnym sposobem „proxy execution”, pozwalającym ukryć złośliwy kod za podpisanym binarium Microsoftu i obchodzić niektóre polityki kontroli aplikacji. Technika ta jest skatalogowana w MITRE ATT&CK jako T1218.011 i szeroko opisywana przez branżę (np. Red Canary).
O kampanii „CAPI Backdoor” jako pierwsi szczegółowo napisali badacze Seqrite; wątek podchwyciły media branżowe, m.in. The Hacker News.

Analiza techniczna / szczegóły luki

Łańcuch infekcji. ZIP o nazwie w języku rosyjskim (np. „Перерасчет заработной платы 01.10.2025”) zawiera:

  1. przynętę PDF o zmianach PIT, 2) skrót LNK o tej samej nazwie. Kliknięcie LNK uruchamia rundll32.exe z parametrami wskazującymi na export „config” w bibliotece adobe.dll (alias client6.dll), co inicjuje komunikację z C2.

Funkcje CAPI Backdoor (wybór):

  • IsAdmin – sprawdza uprawnienia administracyjne przez SID.
  • av – enumeracja zainstalowanych AV przy użyciu zapytań WMI.
  • OpenPdfFile – otwarcie przynęty PDF (kamuflaż).
  • Connect/ReceiveCommands/ExecuteCommand – połączenie TCP na porcie 443 z 91.223.75[.]96, odbiór i wykonywanie poleceń (m.in. listowanie katalogów, exfiltracja).
  • dmp1/dmp2/dmp3 – kradzież profili i kluczy przeglądarek Edge/Chrome/Firefox (pliki historii, zakładki, Local State/klucze).
  • screen – screenshot z oznaczeniem czasu.
  • IsLikelyVm – zestaw heurystyk anty-VM: hypervisor, rejestr, SMBIOS, PnP, OUI MAC, GPU/dostawcy dysków, bateria/chassis, OEM.
  • persist1/persist2 – kopiowanie DLL do AppData\Roaming\Microsoft i autostart przez Startup LNK; dodatkowo Scheduled Task „AdobePDF” (opóźnienie 1 h, cykliczność co godzinę przez 7 dni).

Techniki ATT&CK (mapowanie):

  • T1566.001 – spear-phishing z załącznikiem (ZIP/LNK/PDF).
  • T1218.011 – wykonanie DLL przez rundll32.exe (LOLBAS).
  • T1555.003 – wykradanie poświadczeń/prywatnych danych z przeglądarek. (opisane przez Seqrite w kontekście profili przeglądarek).
  • T1113 – przechwytywanie ekranu.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych klientów i płatności przez eksfiltrację profili przeglądarek (ciasteczka, tokeny sesyjne, historię, hasła – jeśli możliwy dostęp do kluczy lokalnych).
  • Utrzymanie długotrwałego dostępu dzięki podwójnej persystencji (Startup + Scheduled Task).
  • Uwiarygodnienie phishingu przez lokalny kontekst podatkowy (dokument PIT w języku rosyjskim), co zwiększa współczynnik kliknięć.
  • Utrudnione wykrywanie z uwagi na abuse podpisanego binarium rundll32.exe (LOLBIN).

Rekomendacje operacyjne / co zrobić teraz

  1. E-mail & brama: blokowanie archiwów ZIP z plikami .lnk; sandboxing załączników; skan treści w języku lokalnym (ruleset dla słów kluczowych dot. „перерасчет”, „налог”). Mapować kontrole do T1566.001.
  2. EDR/telemetria: alerty na nietypowe wywołania rundll32.exe ładujące z katalogów użytkownika, z parametrem nazwy eksportu (np. config), połączone z komunikacją sieciową. Wspierają to reguły/Sigma i wytyczne LOLBAS.
  3. Kontrola przeglądarek: monitorowanie dostępu do plików profili (Chrome/Edge/Firefox) i nieoczekiwanej kompresji ZIP tych zasobów przez procesy spoza przeglądarek. (na podstawie opisu funkcji dmp1–dmp3).
  4. Persistence hunting: przegląd Startup (lnk) i zadań Harmonogramu (np. „AdobePDF”), w szczególności wpisów wskazujących na rundll32.exe z DLL w AppData\Roaming\Microsoft.
  5. Blokady sieciowe: tymczasowe denylisty dla carprlce[.]ru i 91.223.75[.]96; monitorowanie i blokowanie ruchu wychodzącego TLS do nietypowych hostów/ASN z hostów końcowych.
  6. Szkolenia i symulacje: kampanie uświadamiające o plikach LNK w archiwach ZIP; testy phishingowe imitujące lokalne komunikaty podatkowe. (praktyka zgodna z ATT&CK T1566.*).
  7. Twardnienie stacji roboczych: polityki, które uniemożliwiają uruchamianie DLL z profili użytkowników przez rundll32.exe (AppLocker/WDAC) oraz ograniczenie wykonywania LNK z katalogów tymczasowych. (zob. znane sposoby nadużycia rundll32 i zalecenia branżowe).

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od typowych kampanii z makrami Office, tutaj wektor LNK → rundll32 → DLL minimalizuje zależności od pakietu Office i zwiększa skuteczność na zablokowanych makrach.
  • CAPI łączy stealer + backdoor (zbieranie profili przeglądarek + zadania zdalne), co nadaje mu większą elastyczność niż klasyczne „pure stealers”.

Podsumowanie / kluczowe wnioski

Kampania CAPI Backdoor jest kolejnym przypomnieniem, że LOLBIN-y (tu: rundll32.exe) pozostają skutecznym nośnikiem wykonania w łańcuchach phishingowych. Obrona powinna koncentrować się na telemetrii procesów, korelacji z ruchem sieciowym, łapaniu persystencji oraz higienie załączników (w szczególności ZIP + LNK). Wdrożenie detekcji mapowanych do T1566.001 i T1218.011 oraz regularne polowanie na artefakty Startup/Task Scheduler znacząco ograniczy okno zagrożeń.

Źródła / bibliografia

  1. Seqrite Labs: „Operation MotorBeacon: Threat Actor targets Russian Automotive Sector using .NET Implant”, 17 października 2025 r. (Seqrite)
  2. The Hacker News: „New .NET CAPI Backdoor Targets Russian Auto and E-Commerce Firms via Phishing ZIPs”, 18 października 2025 r. (The Hacker News)
  3. LOLBAS – rundll32.exe (opis nadużyć, ścieżki, przykłady) (lolbas-project.github.io)
  4. MITRE ATT&CK T1218.011 – Signed Binary Proxy Execution: rundll32 (MITRE ATT&CK)
  5. MITRE ATT&CK T1566.001 – Spearphishing Attachment (MITRE ATT&CK)

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ń curlbash 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)

Europol rozbija sieć „SIM farm”: 7 zatrzymanych, 1 200 urządzeń SIM-box i 49 mln fałszywych kont

Wprowadzenie do problemu / definicja luki

Europol (przy wsparciu Eurojustu i służb z Austrii, Estonii, Finlandii oraz Łotwy) rozbił międzynarodową infrastrukturę cybercrime-as-a-service o kryptonimie SIMCARTEL, która wynajmowała przestępcom numery telefoniczne z ponad 80 krajów do rejestracji i weryfikacji kont oraz prowadzenia oszustw. Zatrzymano 7 osób, przeprowadzono 26 przeszukań, zajęto 1 200 urządzeń SIM-box i 40 000 aktywnych kart SIM, a także pięć serwerów i dwie domeny wykorzystywane do świadczenia usługi. Według organów ścigania infrastruktura pomogła utworzyć blisko 50 mln fałszywych kont.

W skrócie

  • Skala: 3 200+ udokumentowanych przypadków oszustw, straty min. ~5 mln € (gł. Austria i Łotwa).
  • Modus operandi: hurtowy wynajem numerów (SIM-farmy/SIM-boxy) do obejścia weryfikacji SMS i ukrywania tożsamości.
  • Seizury: 1 200 SIM-box, 40 000 aktywnych SIM, setki tys. dodatkowych kart, 5 serwerów, mrożenie środków i konfiskata luksusowych aut.
  • Zastosowania przestępcze: phishing/smishing, fałszywe inwestycje, „na córkę/syna” w WhatsApp, podszywanie się pod policję, sklepy-widmo, a także przestępstwa pozatelekomunikacyjne.

Kontekst / historia / powiązania

Eurojust podaje, że platforma udostępniała numery z >80 krajów i była oferowana innym grupom w modelu CaaS (Crime-as-a-Service). Działania operacyjne przeprowadzono 10 października 2025 r., a komunikaty opublikowano 17 października.
Niezależne redakcje (BleepingComputer, CyberScoop, The Record) potwierdzają aresztowania i skalę zabezpieczeń, podając zbliżone szacunki strat: ok. 4,5 mln € w Austrii i ~420 tys. € na Łotwie.

Analiza techniczna / szczegóły luki

SIM-box/SIM-farmy to zestawy bramek GSM z dziesiątkami/setkami gniazd SIM, które automatycznie rotują karty i numery. Dzięki sterowaniu API można masowo:

  • odbierać kody SMS (OTP) do rejestracji kont i resetów haseł,
  • prowadzić smishing na dużą skalę,
  • omijać mechanizmy anty-fraudowe platform (np. limity na numer/urządzenie),
  • maskować geolokalizację i tożsamość operatora.

W sprawie SIMCARTEL infrastruktura działała jak profesjonalna usługa: panel online, automatyzacja, pozyskiwanie kart z wielu rynków, a nawet „oferta” na wynajem numerów i monetyzację cudzych kart. Organy przejęły m.in. serwisy ułatwiające pozyskanie numerów jednorazowych do kodów weryfikacyjnych.

Dlaczego to działa?
Ekosystem SMS-OTP i weryfikacji numeru telefonu jest podatny na nadużycia, bo:

  • SMS nie zapewnia silnego uwierzytelnienia i jest podatny na przekierowania/SS7/małe opóźnienia dostaw,
  • wiele serwisów ufnie traktuje numer jako tożsamość (KBA/„posiadanie”),
  • reputacja numeru jest słabo współdzielona między usługami.

Praktyczne konsekwencje / ryzyko

  • Platformy online: zalew botów i kont-widm (do 49 mln), spadek skuteczności AML/KYC light, nadużycia programów promocyjnych, większe koszty moderacji i ryzyka.
  • Instytucje finansowe: phishing inwestycyjny, podszywanie się, nadużycia „SCA via SMS”.
  • Użytkownicy: ataki „na córkę/syna” w komunikatorach, wyłudzenia danych i środków.
  • Telco: wykorzystanie ich sieci do generowania ruchu A2P, ryzyko reputacyjne i regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

Dla platform i fintechów

  1. Ogranicz zaufanie do SMS-OTP: przejdź na passkeys/FIDO2 jako główny MFA; SMS zostaw jako fallback z dodatkowymi kontrolami ryzyka.
  2. Weryfikacja numeru ≠ weryfikacja tożsamości: zawsze łącz z innymi sygnałami (dokument/biometria, proof-of-personhood).
  3. Inteligencja numerów: HLR/MNP lookups, kontrola klasy usługi (pre-/post-paid), sprawdzanie nowości numeru, scoring reputacji (czy numer był widziany przy wielu rejestracjach).
  4. Anti-abuse na rejestrację: device fingerprinting, velocity rules (na IP/ASN/IMEI-like), limity per metoda płatności, weryfikacje „liveness” w KYC, dynamiczne CAPTCHy.
  5. Monitoring: reguły SIEM/FRM wychwytujące anomalię OTP (dużo SMS na ten sam numer/zakres), alerty na skoki rejestracji z jednego kraju/ASN.

Dla banków i e-commerce

  • Transaction-level MFA (push z bindingiem urządzenia, podpis kryptograficzny), detekcja „social engineering session”.
  • Predefiniowane ostrzeżenia UX i bloki słów kluczowych w komunikacji (np. wzorce „nowy numer dziecka”, „pilny przelew”).

Dla operatorów telekomunikacyjnych

  • Detekcja SIM-box: korelacja IMSI/IMEI, anomalia w TADIG/CellID (duża liczba MSISDN z jednego modemu), nietypowe profile SMS-MT/MO, hurtowa rotacja kart.
  • Współpraca z LEA/CSIRT oraz sinkhole numerów/domen powiązanych z farmami.

Dla użytkowników

  • Nie traktuj SMS jako dowodu tożsamości rozmówcy. Weryfikuj „nowe numery” bliskich innym kanałem. Blokuj linki z SMS/komunikatorów kierujące do płatności/logowania.

Różnice / porównania z innymi przypadkami

W USA we wrześniu 2025 r. tajne służby rozbiły dużą SIM farmę (ponad 300 serwerów i 100 000 kart SIM) wskazując na rosnące ryzyko dla infrastruktury krytycznej. Europa i USA notują więc zbliżoną taktykę, ale inne wektory nadużyć (w UE – silny nacisk na oszustwa konsumenckie i masowe rejestracje kont).

Podsumowanie / kluczowe wnioski

  • SIM-farmy komodytyzują nadużycia oparte na SMS-OTP i deprecjonują numer telefonu jako sygnał zaufania.
  • Organizacje powinny odejść od SMS-OTP jako głównego MFA i wzmocnić kontrole anty-abuse na etapie rejestracji/kontaktu.
  • Współpraca LEA (Europol/Eurojust) z podmiotami prywatnymi i operatorami pozostaje kluczowa do demontażu infrastruktury CaaS.

Źródła / bibliografia

  1. Eurojust: „Decisive action against various online scams in Austria and Latvia: seven arrests”, 17.10.2025. (szczegóły operacji, liczby: 1 200 SIM-box, 40 000 SIM, ~50 mln kont, 26 przeszukań). (Eurojust)
  2. Europol: „Cybercrime-as-a-service takedown: 7 arrested – Operation SIMCARTEL” (komunikat prasowy: aresztowania, przejęte serwisy). (Europol)
  3. BleepingComputer: „Europol dismantles SIM box operation renting numbers for cybercrime”, 17.10.2025 (szacunki strat, przejęte domeny). (BleepingComputer)
  4. CyberScoop: „Europol dismantles cybercrime network linked to $5.8M in financial losses”, 17.10.2025 (dodatkowe liczby, kontekst USA). (CyberScoop)
  5. The Record: „European police bust network selling thousands of phone numbers to scammers”, 17.10.2025 (tło śledztwa, cytaty, materiał wideo policji). (The Record from Recorded Future)

Gladinet łata aktywnie wykorzystywaną lukę zero-day w CentreStack. Co wiemy i co robić?

Wprowadzenie do problemu / definicja luki

Gladinet wydał poprawkę dla CentreStack usuwając wykorzystywaną w atakach lukę CVE-2025-11371 typu Local File Inclusion (LFI). Błąd pozwalał nieautoryzowanym napastnikom odczytać plik Web.config, wyekstrahować ASP.NET machineKey, a następnie zrealizować RCE (zdalne wykonanie kodu) poprzez wcześniej opisaną podatność na deserializację ViewState (CVE-2025-30406). Łatka jest dostępna w CentreStack 16.10.10408.56683.

W skrócie

  • CVE-2025-11371 (LFI) umożliwia odczyt wrażliwych plików (m.in. Web.config) na serwerze CentreStack/Triofox w domyślnej konfiguracji.
  • Ataki obserwowane od 27 września 2025 r. (zero-day).
  • Po pozyskaniu machineKey napastnik może sfałszować ViewState i osiągnąć RCE, łańcuchowo z CVE-2025-30406.
  • Poprawka wydana 14 października 2025 r. w CentreStack 16.10.10408.56683; zalecana natychmiastowa aktualizacja.
  • W okresie bez łatki rekomendowano tymczasową dezaktywizację handlera “temp” w UploadDownloadProxy.

Kontekst / historia / powiązania

W kwietniu 2025 r. naprawiono CVE-2025-30406 (twardo zakodowany machineKey i deserializacja ViewState), która była aktywnie wykorzystywana. Nowa luka LFI (CVE-2025-11371) pozwalała „odtworzyć” warunki do RCE – tym razem poprzez pozyskanie klucza z działającej, już zaktualizowanej instancji. Zależność między CVE-2025-11371 (LFI) i CVE-2025-30406 (RCE) stanowiła kluczowy łańcuch ataku.

Analiza techniczna / szczegóły luki

  • Wektor: niezabezpieczony punkt końcowy /storage/t.dn w komponencie GSUploadDownloadProxy.dll (klasa GladinetStorage.TempDownload). Parametr s= był podatny na directory traversal, umożliwiając odczyt dowolnych plików w kontekście NT AUTHORITY\SYSTEM (np. ...\root\Web.config).
  • Łańcuch do RCE: po odczycie Web.config napastnik uzyskiwał machineKey i mógł wygenerować złośliwy ViewState, aby wykonać komendy z uprawnieniami puli aplikacyjnej IIS (efektywnie przejęcie hosta).
  • Wersje podatne: wg NVD – wszystkie wersje do i włącznie z 16.7.10368.56560 w domyślnej instalacji/konfiguracji.
  • IoC / telemetria zaobserwowana przez Huntress:
    • Żądania GET do **/storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1**
    • Następnie POST-y z base64 (payload ViewState) i logi Event ID 1316 z komendami systemowymi (ipconfig /all > ...).

Praktyczne konsekwencje / ryzyko

  • Ekspozycja klucza kryptograficznego (machineKey) umożliwia podpisywanie złośliwych danych i omijanie zabezpieczeń ViewState → pełne przejęcie serwera.
  • Atak bez uwierzytelnienia, w domyślnej konfiguracji, na systemach często wystawionych do Internetu (MSP, wdrożenia samo-hostowane).
  • Ataki w toku (co najmniej kilku poszkodowanych) i obserwacje od końca września zwiększają pilność działań.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj CentreStack do 16.10.10408.56683 (lub nowszej). Zweryfikuj numer buildu po instalacji.
  2. Jeśli aktualizacja chwilowo niemożliwa: wyłącz handler „temp” w UploadDownloadProxy\Web.config (usunięcie mapowania do t.dn). Uwaga: ogranicza funkcjonalność, ale zamyka wektor LFI.
  3. Hunting/Monitoring:
    • Szukaj żądań do **/storage/t.dn** z ciągami ..\..\.. i odczytem Web.config.
    • Analizuj logi aplikacyjne (np. Event ID 1316) pod kątem nietypowych payloadów base64 i komend systemowych.
  4. Twardnij konfigurację ASP.NET: rotacja machineKey po incydencie, wymuszenie minimalnych uprawnień puli aplikacyjnej, kontrola dostępu do ścieżek tymczasowych. (Wniosek na podstawie analizy łańcucha ataku).
  5. Przegląd ekspozycji: potwierdź, czy interfejsy CentreStack/Triofox są dostępne z Internetu; jeśli tak, rozważ geofencing/VPN/WAF i reguły sygnaturowe na /storage/t.dn.
  6. Triofox: produkt był wskazany jako podatny w domyślnej konfiguracji; sprawdź komunikaty producenta i dostępność aktualizacji dla Twojej wersji Triofox (w artykułach potwierdzono patch publicznie dla CentreStack).

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 vs CVE-2025-30406:
    • 11371 = LFI (odczyt plików) → pośrednio umożliwia RCE przez 30406 (ViewState).
    • 30406 = krytyczna deserializacja możliwa przy znajomości machineKey (wcześniej twardo zakodowanego); naprawiona w kwietniu 2025 r. 11371 „odblokowała” 30406 na zaktualizowanych hostach przez ujawnienie klucza.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj teraz do 16.10.10408.56683 – to jedyny trwały sposób zamknięcia LFI.
  • Sprawdź logi pod kątem odczytów Web.config przez /storage/t.dn i podejrzanych payloadów base64 – to typowy ślad tej kampanii.
  • Traktuj 11371 + 30406 jako łańcuch: sama „średnia” punktacja LFI (CVSS 6.2) jest myląca – w praktyce prowadzi do pełnego RCE.

Źródła / bibliografia

  1. BleepingComputer – „Gladinet fixes actively exploited zero-day in file-sharing software” (wydanie łatki, wersja 16.10.10408.56683, wektor /storage/t.dn). (BleepingComputer)
  2. Huntress – „Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (CVE-2025-11371)” (timeline, IoC, technikalia, mitigacje, potwierdzenie daty wydania łatki). (Huntress)
  3. SecurityWeek – „Gladinet Patches Exploited CentreStack Vulnerability” (podsumowanie łańcucha LFI → ViewState RCE, potwierdzenie wersji z poprawką). (SecurityWeek)
  4. NVD – CVE-2025-11371 (opis wpływu i zakres wersji w domyślnej konfiguracji). (NVD)
  5. Field Effect – „Gladinet patches critical vulnerability exploited in the wild” (daty: obserwacje, publikacja mitigacji i wydanie poprawki). (fieldeffect.com)

Hack własności: włamanie do Sotheby’s ujawniło numery SSN i dane finansowe

Wprowadzenie do problemu / definicja luki

Dom aukcyjny Sotheby’s poinformował o naruszeniu bezpieczeństwa danych, w wyniku którego napastnicy wykradli dane osobowe o podwyższonej wrażliwości. W zawłaszczonych plikach znajdowały się m.in. imiona i nazwiska, numery Social Security (SSN) oraz informacje o rachunkach finansowych. Firma wykryła intruzję 24 lipca 2025 r., a powiadomienia do osób dotkniętych incydentem zaczęła wysyłać 15 października 2025 r.

W skrócie

  • Data wykrycia: 24 lipca 2025 r.
  • Zakres danych: imię i nazwisko, SSN, dane rachunków finansowych (zakres może różnić się w zależności od osoby).
  • Powiadomienia: listownie od 15 października 2025 r.; oferowany 12-miesięczny monitoring kredytowy (TransUnion).
  • Skala (dotychczas ujawniona): co najmniej 2 osoby w Maine i 10 w Massachusetts; łączna liczba nieujawniona (na ten moment wygląda na ograniczoną).
  • Atrybucja / ransomware: brak potwierdzenia; żadna znana grupa nie przyznała się do włamania.

Kontekst / historia / powiązania

Incydent został upubliczniony po złożeniu zawiadomień u prokuratorów stanowych (Attorney General). Rejestr stanu Maine oraz kopia listu do poszkodowanych potwierdzają typy danych i daty powiadomień. Media branżowe (SecurityWeek, BleepingComputer, The Register) zebrały dodatkowe szczegóły — m.in. to, że Sotheby’s nie potwierdziło, czy ofiarami są klienci, czy pracownicy, oraz że brak jest dowodów na wymuszenie okupu.

Analiza techniczna / szczegóły luki

Szczegóły techniczne wektora wejścia nie zostały ujawnione. Z perspektywy TTP możliwe scenariusze (hipotezy zgodne z MITRE ATT&CK), które często prowadzą do podobnych incydentów w organizacjach z wysokowartościowymi danymi, to:

  • Phishing/credential harvesting (T1566) → przejęcie konta i dostęp do udziałów plikowych.
  • Wykorzystanie słabych/starych poświadczeń (T1110) lub błąd w SSO/IdP.
  • Dostęp przez usługę zewnętrzną / partnera (T1199), co bywa typowe w ekosystemach z licznymi dostawcami i domami aukcyjnymi.

Czas między wykryciem (24.07) a zakończeniem przeglądu danych i identyfikacją osób (ok. 2 miesiące) sugeruje klasyczny „data mining & validation” po incydencie — żmudną weryfikację zakresu PII w przejętych plikach. (Wniosek na podstawie osi czasu raportowanej publicznie).

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości i nadużyć finansowych (SSN + dane rachunkowe to komplet pozwalający na otwieranie kont/wnioskowanie o kredyt).
  • Spear-phishing i oszustwa „high-net-worth”: klienci domu aukcyjnego to często osoby/instytucje o wysokim statusie majątkowym; ich rekordy są wyjątkowo łakomym kąskiem dla oszustów.
  • Ryzyko wtórnych ataków na pracowników (jeśli to ich dane wyciekły), np. fraud płacowy, SIM-swap.
  • Ryzyko prawne i regulacyjne (stanowe przepisy dot. powiadamiania, możliwe pozwy zbiorowe). Potwierdzają to wnioski i publikacje AG w Maine/Massachusetts.

Rekomendacje operacyjne / co zrobić teraz

Dla osób, które otrzymały list:

  1. Aktywuj monitoring kredytowy (TransUnion, 12 mies.) i rozważ zamrożenie kredytu we wszystkich biurach (Equifax, Experian, TransUnion).
  2. Włącz alerty transakcyjne w banku, zmień PIN-y/hasła powiązane z rachunkami.
  3. Uważaj na celowane wiadomości podszywające się pod Sotheby’s/banki (verbal call-back przez numer z karty/banku).

Dla SOC/IT w instytucjach o podobnym profilu:

  • Containment & telemetry: pełna telemetria EDR/XDR na serwerach plików i systemach, gdzie przechowywane są PII/FIN; DLP na kanałach e-mail/SaaS.
  • Identity hardening: enforce FIDO2/Passkeys dla kont z dostępem do danych klientów; PAM dla uprzywilejowanych; MFA phishing-resistant.
  • Data minimization & encryption: klasyfikacja i szyfrowanie at-rest PII/FIN; tokenizacja przy wymianie z partnerami.
  • Third-party risk: przegląd dostawców (galerie, logistyka sztuki, escrow, płatności), just-in-time access, SCP.
  • Tabletop & IR: ćwiczenia scenariusza exfiltration without extortion (brak noty okupu ≠ brak ryzyka).
  • KPIs: MTTD/MTTR dla anomalii w ruchu SMB/SharePoint; wskaźniki exfil (np. wolumeny do chmur publicznych).

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

W odróżnieniu od typowych w 2024–2025 r. wycieków połączonych z ransomware + wyciek danych, tu — na dziś — brak publicznego przypisania do grupy i brak żądania okupu. Skala (na podstawie danych z AG Maine/Massachusetts) wygląda na ograniczoną, co zbliża incydent do ukierunkowanej eksfiltracji zamiast masowego „smash-and-grab”.

Podsumowanie / kluczowe wnioski

  • W Sotheby’s doszło do kradzieży danych wrażliwych (SSN, informacje finansowe).
  • Oś czasu: 24.07 wykrycie → 15.10 notyfikacje; wstępnie brak śladów ransomware/publicznej presji.
  • Na dziś ujawniona skala (Maine: 2 osoby; Massachusetts: 10) sugeruje incydent o ograniczonym zasięgu, ale z wysokim ryzykiem indywidualnym.
  • Priorytetem są: monitoring kredytowy, zamrożenie kredytów, twardnienie tożsamości i ścisły nadzór nad danymi finansowymi.

Źródła / bibliografia

  • SecurityWeek — „Hackers Steal Sensitive Data From Auction House Sotheby’s” (17 października 2025). (SecurityWeek)
  • BleepingComputer — „Auction giant Sotheby’s says data breach exposed customer information” (16–17 października 2025). (BleepingComputer)
  • The Register — „Sotheby’s finds its data on the block after cyberattack” (16 października 2025). (The Register)
  • Biuro Prokuratora Generalnego stanu Maine — karta zdarzenia i PDF z listem do poszkodowanych (15 października 2025). (Maine)
  • Massachusetts AG — „Data Breach Notification Reports” (strona wykazów; wpis dot. 10 mieszkańców MA raportowany m.in. przez SecurityWeek). (Massachusetts Government)

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)