Archiwa: Malware - Strona 121 z 125 - Security Bez Tabu

Atak łańcuchowy na rozszerzenia VS Code z malware „GlassWorm”. Niewidzialny kod, C2 na blockchainie i samopropagacja

Wprowadzenie do problemu / definicja luki

W połowie października 2025 r. wykryto wysoce zaawansowany atak łańcuchowy na ekosystem rozszerzeń dla VS Code. Kampania, nazwana GlassWorm, infekuje rozszerzenia publikowane w OpenVSX (alternatywny, otwarty rejestr) i w pojedynczych przypadkach w Visual Studio Code Marketplace. Celem jest kradzież tokenów NPM/GitHub/Git (i innych), drenaż środków z 49 wtyczek kryptowalutowych, a także przejęcie stacji roboczych deweloperów jako węzłów infrastruktury przestępczej (SOCKS proxy, ukryty VNC). Atak rozpowszechnia się sam — używa przejętych poświadczeń do kompromitowania kolejnych rozszerzeń/pakietów. Pierwsze zainfekowane wydania w OpenVSX pojawiły się 17 października 2025 r.; do 20–21 października potwierdzono ok. 35,8 tys. instalacji złośliwych wersji.

W skrócie

  • Wejście: zainfekowane rozszerzenia VS Code w OpenVSX (i jeden przypadek w oficjalnym marketplace Microsoftu).
  • Technika ukrycia: „niewidzialny kod” oparty o Unicode variation selectors – złośliwy JS nie renderuje się w edytorze i znika w diffach.
  • C2: łańcuch Solana (memo w transakcjach zawiera wskaźnik do ładunku) + Google Calendar jako zapasowy kanał + bezpośrednie IP.
  • Zdolności: exfiltracja sekretów (NPM, GitHub, OpenVSX, Git), drenaż portfeli krypto (49 rozszerzeń), SOCKS proxy, HVNC, P2P (WebRTC), DHT, samopropagacja.
  • Skala: min. 35,8 tys. instalacji; co najmniej 7 rozszerzeń w OpenVSX na starcie, kolejne dołączane w toku.

Kontekst / historia / powiązania

GlassWorm pojawia się miesiąc po kampanii Shai Hulud (samopropagujący się robak w ekosystemie npm), również opisanej przez Koi Security. Wcześniej w 2025 r. społeczność zwracała uwagę na ryzyka marketplace’ów VS Code/OpenVSX (m.in. wycieki sekretów i słabe procesy publikacji). Choć podatność procesu publikacji w OpenVSX zgłoszona w maju i załatana w czerwcu nie miała potwierdzonego nadużycia, łańcuch dostaw rozszerzeń pozostaje atrakcyjny dla atakujących. GlassWorm pokazuje kolejny krok — połączenie samopropagacji z infrastrukturą C2 odporną na „takedown”.

Analiza techniczna / szczegóły luki

Niewidzialny kod (Unicode):
Złośliwe fragmenty są wstrzykiwane z użyciem Unicode variation selectors, które nie generują widocznego znaku. W efekcie w edytorze i w przeglądarce diffów widać „puste” linie; interpreter JS nadal wykonuje payload. To znacząco obniża skuteczność przeglądu kodu i części narzędzi SAST.

  1. Solana – malware wyszukuje transakcje z określonego portfela i odczytuje memo z zaszytym (base64) linkiem do kolejnego etapu; zmiana ładunku to publikacja nowej transakcji (tani, dynamiczny i odporny na usunięcie kanał).
  2. Google Calendar – tytuł wydarzenia zawiera kolejny wskaźnik URL (backup C2).
  3. Bezpośrednie IP – serwer serwujący zaszyfrowane ładunki, z kluczem AES przekazywanym w nagłówkach HTTP.

Łańcuch infekcji i moduły:

  • Etap kradzieży: pozyskanie tokenów NPM/GitHub/Git/OpenVSX + dane z 49 rozszerzeń portfeli kryptowalut.
  • Samopropagacja: użycie skradzionych poświadczeń do publikacji zainfekowanych wersji pakietów/rozszerzeń.
  • „ZOMBI”: aktywacja SOCKS proxy, WebRTC P2P, BitTorrent DHT do dystrybucji komend oraz HVNC (ukryty zdalny pulpit) — pełny, niewidoczny dostęp do stacji roboczej.

Skala i czas:

  • Start: 17 października 2025 – 7 rozszerzeń OpenVSX.
  • 18–21 października: ~35,8 tys. instalacji, kolejne rozszerzenia aktywnie serwowały malware; wykryto też pojedyncze zainfekowane rozszerzenie w Microsoft VS Code Marketplace (usunięte po zgłoszeniu).

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: każdy zainfekowany deweloper staje się wektorem do przejęcia następnych rozszerzeń i repozytoriów.
  • Utrata sekretów i eskalacja: wyciek tokenów repozytoryjnych i rejestrów pakietów = możliwość publikacji trojanizowanych wersji oprogramowania.
  • Pivot do sieci wewnętrznej: HVNC + SOCKS czynią z laptopów deweloperów ukryte backdoory i węzły pośredniczące.
  • Trwałość i odporność na wyłączenie: C2 oparte na blockchainie i usługach chmurowych utrudnia neutralizację i blokowanie.

Rekomendacje operacyjne / co zrobić teraz

Traktuj to jako aktywny incydent, nie tylko „podatność”. Poniżej lista działań priorytetowych:

  1. Natychmiastowa higiena i izolacja
  • Odłącz stacje deweloperskie od sieci firmowej; zablokuj wyjścia do: znanych IoC (np. 217.69.3.218, 140.82.52.31), RPC Solany i wskazanego wydarzenia Google Calendar (blok domenowy/aplikacyjny).
  • Tymczasowo wyłącz auto-aktualizacje rozszerzeń w IDE; wstrzymaj instalacje z OpenVSX i niezweryfikowanych marketplace’ów.
  1. Łańcuch tożsamości i sekretów
  • Rotacja wszystkich sekretów używanych na stacjach deweloperskich: tokeny NPM/GitHub/Git/OpenVSX/VS Code, hasła, klucze SSH; unieważnij sesje.
  • Wymuś re-login po rotacji, włącz obowiązkowo MFA i zasady urządzeń zaufanych.
  1. Triaga i detekcja
  • Przeskanuj hosty pod kątem: procesów HVNC, uruchomionych SOCKS proxy, komponentów WebRTC P2P, wpisów autostartu HKCU/HKLM...\Run, artefaktów z listy IoC Koi.
  • Monitoruj nietypowe połączenia wychodzące (Solana RPC, kalendarz Google, nietypowe IP HTTP z nagłówkami niestandardowymi).
  1. Remediacja hostów
  • Pełny reimage zaufanym obrazem → odtworzenie środowiska developerskiego → dopiero potem przywracanie dostępu do repozytoriów/registrów. (Rekomendowane przez badaczy w związku z HVNC i trwałością modułów).
  1. Zarządzanie ryzykiem marketplace’ów
  • Wprowadź allow-listę rozszerzeń (zarządzanie katalogiem dopuszczonych dodatków), SBOM dla pluginów oraz cykliczny przegląd autorów/łańcucha wydawniczego.
  • Rozważ blokadę OpenVSX w sieci korporacyjnej do czasu pełnego wyjaśnienia; zezwalaj wyłącznie na oficjalny marketplace i/lub wewnętrzne mirrory z walidacją.
  1. Długofalowo
  • Włącz skanery sekretów i SCA dla rozszerzeń i pakietów developerskich; egzekwuj zasady „no tokens in builds”.
  • Edukuj dev-teamy o wektorach „niewidzialnego kodu” (Unicode), kontroluj diffy w trybie view raw bytes lub z narzędziami wykrywającymi znaki kontrolne.

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

  • Shai Hulud (npm, IX 2025) – pierwszy robak samopropagujący w ekosystemie npm (kradł tokeny i publikował zainfekowane wersje). GlassWorm adaptuje ten model do OpenVSX/VS Code i dodaje niewidzialny kod + C2 na blockchainie + HVNC (większa odporność i wpływ na hosta).
  • WhiteCobra / fale złośliwych rozszerzeń – wcześniejsze kampanie (stealery) bazowały głównie na exfiltracji; GlassWorm tworzy żyjący ekosystem z P2P/DHT/HVNC i realnym „przejęciem” stacji. (Wskazuje to trend eskalacji w marketplace’ach IDE).

Podsumowanie / kluczowe wnioski

GlassWorm to punkt zwrotny dla bezpieczeństwa rozszerzeń IDE: łączy trik steganograficzny (Unicode), C2 odporny na likwidację (Solana/Google Calendar) i robakową samopropagację. Organizacje korzystające z VS Code i pochodnych narzędzi powinny potraktować sprawę jak incydent średnio-/wysokiego ryzyka, nie czekać na listy „złych rozszerzeń” i wdrożyć rotację sekretów + reimage najbardziej narażonych hostów developerskich.

Źródła / bibliografia

  • SecurityWeek: „Supply Chain Attack Targets VS Code Extensions With ‘GlassWorm’ Malware”, 21 października 2025. (SecurityWeek)
  • Koi Security (analiza techniczna), 18 października 2025. (koi.ai)
  • Koi Security (strona incydentu z IoC i aktualizacjami), 20 października 2025. (koi.ai)
  • Dark Reading: „Self-Propagating GlassWorm Attacks VS Code Supply Chain”, 20 października 2025. (Dark Reading)
  • CSO Online/InfoWorld: „Self-propagating worm found in marketplaces for VS Code extensions”, 21 października 2025. (CSO Online)

Microsoft Digital Defense Report 2025: AI przyspiesza ewolucję ataków. Czas porzucić wyłącznie „tradycyjne” zabezpieczenia

Wprowadzenie do problemu / definicja luki

Microsoft opublikował najnowszy Digital Defense Report 2025 (MDDR), obejmujący trendy od lipca 2024 do czerwca 2025. Konkluzja jest jasna: AI stała się mnożnikiem siły zarówno dla obrońców, jak i napastników, a poleganie wyłącznie na klasycznych, „perymetrycznych” kontrolach nie wystarczy wobec skali i szybkości współczesnych kampanii. Ponad połowa ataków z ustalonym motywem była napędzana ekstorcją i ransomware, podczas gdy operacje czysto szpiegowskie to zaledwie kilka procent spraw.

W skrócie

  • Ekstorcja/ransomware >50% incydentów z ustalonym motywem (co najmniej 52%); szpiegostwo ~4%.
  • „Nie włamują się — logują się”: wzrost ataków tożsamościowych i roli infostealerów; 97% ataków na tożsamość to ataki hasłowe.
  • AI przyspiesza: generowanie treści socjotechnicznych, automatyzacja ruchu bocznego, wyszukiwanie luk, real-time evasions; jednocześnie same systemy AI stają się celem (prompt injection, data poisoning).
  • Najczęściej atakowane sektory: administracja publiczna i IT; w TOP10 także badania/akademia, NGO, produkcja krytyczna, transport.
  • Najmocniej dotknięte kraje (H1 2025): USA, UK, Izrael, Niemcy.
  • Wniosek strategiczny: modernizacja zabezpieczeń (identity-first, phishing-resistant MFA), odporność chmury, łańcuchy dostaw i współpraca publiczno-prywatna.

Kontekst / historia / powiązania

Tegoroczny raport to szósta edycja MDDR i odzwierciedla przesunięcie ciężaru z incydentów „czysto technicznych” na zdarzenia wpływające na usługi krytyczne oraz codzienne życie (od szpitali po transport). Microsoft akcentuje, że to już problem całospołeczny, wymagający zarówno modernizacji technologii, jak i konsekwencji polityczno-prawnych wobec agresorów (w tym państw narodowych korzystających z ekosystemu cyberprzestępczego).

Analiza techniczna / szczegóły raportu

1) Motywacja i taktyki

  • Ekstorcja odpowiada za ~33% celów w angażach IR, ludzkie/niszczące ransomware ~19%, a faktyczne wdrożenie ładunku ~8%; czyste szpiegostwo ~4%.
  • Kampanie łączą socjotechnikę z eksploatacją techniczną. Na znaczeniu zyskały ClickFix oraz device code phishing, a nadużycia OAuth/legacy auth/AiTM umożliwiają długotrwały dostęp mimo MFA.

2) Wejście początkowe (Initial Access)

  • Wektor „valid accounts”/kradzione sesje zyskuje, a napastnicy coraz częściej „logują się” dzięki infostealerom i wyciekłym danym uwierzytelniającym. Trwa szybka weaponizacja znanych CVE przeciw usługom wystawionym do Internetu i zdalnym usługom.

3) Sektory i geografia

  • Administracja i IT w czołówce celów; w TOP10 również badania/akademia, NGO, produkcja krytyczna, transport, telco, finanse, zdrowie. Największa koncentracja ataków w USA, UK, Izraelu i Niemczech (H1 2025).

4) AI – miecz obosieczny

  • Napastnicy wykorzystują generatywną AI do skalowania phishingu/socjotechniki, odkrywania luk i adaptacyjnego malware; równocześnie rosną ataki na same systemy AI (prompt injection, data poisoning). Po stronie obrony AI skraca detekcję i reakcję oraz redukuje luki w wykrywaniu.

5) Incydent o potencjale systemowym

  • W lutym 2025 udaremniono atak ransomware na globalnego operatora żeglugi – szyfrowanie zatrzymano po 68 sekundach, a całość rozbito w 14 minut; zdarzenie pokazuje kaskadowe ryzyko dla łańcuchów dostaw.

Praktyczne konsekwencje / ryzyko

  • Tożsamość i sesje są najprostszą drogą wejścia (kradzieże haseł/sesji, kupowanie dostępu). Brak phishing-resistant MFA i kontroli aplikacji/OAuth = podwyższone ryzyko trwałej kompromitacji.
  • Szybka weaponizacja CVE skraca okno patchowania; organizacje o wolnych procesach aktualizacji będą statystycznie padać ofiarą skanów-at-scale.
  • AI-first kampanie zwiększają wolumen i jakość socjotechniki (syntetyczne treści, automatyzacja), a atakowana AI może stać się przekaźnikiem błędnych decyzji (np. zatruwanie danych, wstrzykiwanie promptów).
  • Usługi krytyczne i sektor publiczny są narażone na realny wpływ (zdrowie, edukacja, służby). Wymagana jest współpraca z rządami i egzekwowanie konsekwencji wobec agresorów.

Rekomendacje operacyjne / co zrobić teraz

Na bazie zaleceń MDDR i praktyk defensywnych:

  1. Identity-First Security
  • Phishing-resistant MFA (FIDO2/Passkeys) dla wszystkich ról – priorytet dla kont uprzywilejowanych.
  • Warunki dostępu (Conditional Access), governance aplikacji/OAuth, ciągłe monitorowanie tokenów; eliminacja legacy auth.
  1. Twarda higiena i ekspozycja
  • Inwentaryzacja usług public-facing, skanowanie i szybkie łatanie; SLA na patch skrócone do dni/godzin przy krytycznych CVE.
  • Wymuszenie Secure by Default: EDR/AV, blokady makr, kontrola PowerShell, Least Privilege.
  1. Odporność chmury i danych
  • Segregacja tożsamości (admin/workload), Just-in-Time/Just-Enough-Access, separacja tenants/subskrypcji.
  • Kopie niezmienialne (immutability), testy odtwarzania, segmentacja sieci.
  1. AI Security
  • Threat modeling dla AI: ochrona przed prompt injection, data poisoning, wyciekiem danych z modeli; kontrola dostępu do modeli i pipeline’ów ML.
  1. Detekcja zachowań i automatyzacja reakcji
  • Telemetria z tożsamości, punktów końcowych, chmury i poczty; korelacja oparta na zachowaniach; SOAR do skracania MTTR.
  1. Łańcuch dostaw i third parties
  • Ocena ryzyka dostawców (m.in. nadużycia zaufanych relacji), minimalizacja dostępu stałego, monitoring anomalii integracji.
  1. Governance i współpraca
  • Raportowanie do zarządu (metryki: pokrycie MFA, czas łatania, MTTR, incydenty/semestr).
  • Współpraca z CERT/CSIRT oraz branżą (dzielenie się TTP, IOCs) i egzekwowanie konsekwencji wobec agresorów.
  1. Horyzont PQC (post-quantum)
  • Inwentaryzacja miejsc użycia kryptografii i plan migracji do post-quantum crypto zgodnie z ewolucją standardów.

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

W porównaniu z wcześniejszymi edycjami MDDR, tegoroczny raport wyraźniej eksponuje skalę operacji państw narodowych (m.in. wzrost rosyjskiej aktywności wobec państw NATO) przy jednoczesnym stwierdzeniu, że głównym wolumenem nadal są kampanie przestępcze nastawione na zysk. To koreluje z doniesieniami mediów o rosnącym użyciu AI w operacjach wpływu i kampaniach technicznych.

Podsumowanie / kluczowe wnioski

  • AI zmienia dynamikę: zwiększa efektywność ataków i obrony — wygrywa strona, która szybciej i mądrzej ją wdroży.
  • Tożsamość to nowy perymetr: MFA odporne na phishing, governance aplikacji i higiena tokenów to absolutne „must have”.
  • Odporność organizacyjna > pojedyncze narzędzia: modernizacja procesów, automatyzacja reakcji i przygotowanie na zakłócenia łańcuchów dostaw.
  • Współpraca i polityka są tak samo ważne, jak technologia — bez nich odstraszanie agresorów będzie nieskuteczne.

Źródła / bibliografia

  1. Microsoft Digital Defense Report 2025 (pełny PDF). Kluczowe dane: sektory, geografia, motywy, timeline incydentu w transporcie. (Microsoft)
  2. Microsoft – CISO Executive Summary (PDF). Nowe trendy: ClickFix, device code phishing, nadużycia OAuth; AI jako cel ataku. (Microsoft)
  3. Microsoft Security / On the Issues – MDDR 2025 (blog, 16.10.2025). Zakres czasowy, 52% ataków motywowanych zyskiem, 97% ataków tożsamościowych hasłowych, rola MFA. (The Official Microsoft Blog)
  4. Microsoft – strona raportu (Security Insider). Priorytety obronne: tożsamość, odporność chmury, łańcuchy dostaw, partnerstwa. (Microsoft)
  5. Industrial Cyber – omówienie (21.10.2025). Kontekst dla OT/CI, wątki polityki odstraszania i governance. (Industrial Cyber)

Hakerzy wykorzystali SnappyBee (Deed RAT) i lukę w Citrix NetScaler do ataku na europejskiego operatora telekomunikacyjnego

Wprowadzenie do problemu / definicja luki

Na początku lipca 2025 r. europejski dostawca usług telekomunikacyjnych został zaatakowany przez aktora powiązanego z Chinami, śledzonego jako Salt Typhoon (aka Earth Estries / FamousSparrow / GhostEmperor / UNC5807/UNC2286). Wektor wejścia stanowił Citrix NetScaler Gateway (dawniej ADC/Gateway), a po uzyskaniu przyczółka napastnicy przeszli na hosty Citrix Virtual Delivery Agent (VDA) w segmencie Machine Creation Services (MCS). W dalszej fazie zastosowano DLL sideloading z wykorzystaniem podpisanych plików znanego oprogramowania AV oraz wdrożono backdoora SnappyBee (Deed RAT) – uważanego za następcę ShadowPad. Incydent wykryto i zneutralizowano we wczesnym etapie.


W skrócie

  • Aktor: Salt Typhoon (chińska grupa APT ukierunkowana na telekomy i infrastrukturę krytyczną).
  • Wejście: eksploatacja urządzenia Citrix NetScaler Gateway i pivot do hostów Citrix VDA (MCS).
  • Ukrycie: ruch przez SoftEther VPN oraz DLL sideloading na bazie legalnych plików AV (Norton, Bkav, IObit).
  • Malware: SnappyBee/Deed RAT – łańcuch pokrewieństwa do ShadowPad.
  • C2: kontakt z aar.gandhibludtric[.]com (HTTP i niestandardowy TCP).

Kontekst / historia / powiązania

Salt Typhoon od 2019 r. prowadzi długotrwałe kampanie cyberszpiegowskie wobec operatorów telekomunikacyjnych, administracji i sektora energii – na wielu kontynentach. W latach 2024–2025 szereg doniesień (m.in. Reuters) wskazywał na skoordynowane włamania do sieci telekomów w USA i innych krajach, o dużej głębokości utrzymania się w środowiskach ofiar. Amerykańskie instytucje publiczne publikowały ostrzeżenia i środki zaradcze wobec działań aktorów sponsorowanych przez władze ChRL.

Trend Micro profiluje „Earth Estries” jako grupę o bogatym arsenale – od SnappyBee (Deed RAT) po inne niestandardowe implanty – oraz stałej preferencji do utrzymywania się w sieciach telekomunikacyjnych przez długie okresy.


Analiza techniczna / szczegóły luki

Wejście i pivot:

  • Eksploatacja bramy Citrix NetScaler Gateway → ruch atakującego widoczny z zasobów powiązanych z SoftEther VPN (maskowanie pochodzenia).
  • Później pivot do hostów Citrix VDA w podsieci MCS – logiczny krok po przejęciu bramy dostępowej w środowiskach wirtualnych pulpitów.

Egzekucja i ukrywanie (Defense Evasion):

  • DLL sideloading: dostarczenie złośliwych bibliotek w pakiecie z legalnymi EXE antywirusów (Norton AV, Bkav AV, IObit Malware Fighter). To znana technika wielu chińskojęzycznych grup – pozwala ominąć kontrole aplikacji i EDR bazujące na reputacji.

Backdoor / ładunek:

  • SnappyBee (aka Deed RAT) – opisywany jako następca modularnego ShadowPad. Umożliwia zdalne sterowanie, eksfiltrację i rozbudowę funkcji. W innych kampaniach obserwowano rozwinięte „linie rodowe”, np. BLOODALCHEMY jako warianty Deed RAT.

C2 i łączność:

  • Observed C2: aar.gandhibludtric[.]com (HTTP + nieokreślony protokół TCP). Sugeruje hybrydowy model komunikacji i próby mieszania się z ruchem webowym.

Techniki MITRE ATT&CK (mapowanie przykładowe):

  • Initial Access: Exploiting Public-Facing Application (T1190) – urządzenia brzegowe.
  • Defense Evasion/Execution: DLL Search Order Hijacking (T1574.001), Signed Binary Proxy Execution (T1218).
  • Command and Control: Application Layer Protocol – Web Protocols (T1071.001), Non-Standard Port (T1571).
    (Uzasadnienie na bazie opisu Darktrace i zgodności z wcześniejszymi TTP Earth Estries).

Praktyczne konsekwencje / ryzyko

  • Telekomy jako cel o wysokiej wartości: przejęcie bramy zdalnego dostępu (NetScaler) i pivot do VDI zwiększa ryzyko dostępu do systemów OSS/BSS, podsłuchu, danych abonentów, a nawet ruchu sygnalizacyjnego. Globalne doniesienia z 2024–2025 r. potwierdzają, że Salt Typhoon potrafi osiągać głęboki poziom uprzywilejowania i długą obecność.
  • DLL sideloading przez „zaufane” EXE: utrudnia detekcję opartą o reputację i listy zaufanych wydawców – ryzyko false negative w EDR bez silnej telemetrii modułów ładowanych do procesu.
  • SoftEther i inne kanały maskujące: komplikują śledzenie źródeł i korelację zdarzeń na brzegu sieci.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowy przegląd i hardening NetScaler/NetScaler Gateway
    • Upewnij się, że bramy są na najnowszych wersjach i że konfiguracje AAA/Gateway są zgodne z zaleceniami producenta.
    • Włącz nacisk na monitoring anomalii w ruchu do/od urządzeń brzegowych (szczególnie HTTP(S) do nietypowych hostów).
    • Zestaw kontrolek dla Citrix VDA/MCS: ograniczenie lateral movement (mikrosegmentacja, ACL, firewall hostowy).
      (Ogólne zalecenia wynikają z opisu wektora w raporcie Darktrace i ostrzeżeń instytucji dot. PRC aktorów).
  2. Polityki anty-sideloading i „living off trusted binaries”
    • Block/Allow-list na poziomie DLL search order i ścieżek ładowania bibliotek dla aplikacji krytycznych (w tym AV).
    • W EDR/XDR twórz reguły detekcyjne dla: signed EXE + niepodpisany/nieznany DLL w katalogu aplikacji, nieoczekiwane moduły w procesach AV.
  3. Myśli przewodnie dla detekcji C2
    • Reguły na nietypowe domeny oraz C2 over HTTP + nietypowy TCP; korelacja z danymi DNS/SSL SNI (np. „aar.gandhibludtric[.]com”).
    • Uważna inspekcja tuneli VPN typu SoftEther i innych user-space VPN.
  4. Higiena tożsamości i segmentacja
    • MFA, rotacja haseł uprzywilejowanych, Just-In-Time dostępy dla adminów VDI/VDA, tiering kont i serwerów.
    • Mikrosegmentacja podsieci VDI/MCS oraz ograniczenia RDP/SMB z bramy do VDA tylko wg zasady najmniejszych uprawnień.
  5. Ćwiczenia IR + playbook pod APT
    • Scenariusz: kompromitacja urządzenia brzegowego + pivot do VDI + DLL sideloading.
    • Włącz w playbook pre-collection artefaktów: listy załadowanych modułów, ścieżki DLL, telemetry z NetScaler/Gateway i VDA.

Różnice / porównania z innymi przypadkami (telekomy 2024–2025)

W porównaniu do ujawnionych w 2024–2025 r. kampanii Salt Typhoon przeciwko telekomom w USA (AT&T, Verizon i inni), obecny przypadek z UE pokazuje zbliżony modus operandi: wejście przez urządzenia brzegowe, długotrwałość, nacisk na ukrycie i pozyskiwanie danych o wysokiej wartości. Elementem wyróżniającym jest udokumentowane użycie SnappyBee/Deed RAT dostarczanego przez DLL sideloading na bazie plików AV, co Darktrace opisuje bardzo konkretnie dla tej operacji.


Podsumowanie / kluczowe wnioski

  • Salt Typhoon pozostaje jednym z najgroźniejszych aktorów dla telekomów – atakuje edge (Citrix), szybko pivotuje do VDI i utrzymuje się dzięki sideloadingowi i niestandardowym backdoorom (SnappyBee/Deed RAT).
  • Nawet podpisane i „zaufane” binaria (AV) mogą stać się nośnikiem ładunków – procesy AV trzeba monitorować jak aplikacje wysokiego ryzyka.
  • Obrona wymaga twardych aktualizacji Citrix, telemetrii DLL, dyscypliny segmentacyjnej w VDI/MCS oraz analityki C2. Zalecenia CISA dot. aktorów państwowych wspierają takie podejście.

Źródła / bibliografia

  1. Darktrace – opis incydentu i TTP: „Darktrace’s view on a recent Salt Typhoon intrusion” (opublikowano 20 października 2025). (darktrace.com)
  2. The Hacker News – „Hackers Used Snappybee Malware and Citrix Flaw to Breach European Telecom Network” (21 października 2025). (The Hacker News)
  3. Trend Micro – „Breaking Down Earth Estries’ Persistent TTPs in Prolonged Cyber Operations” (8 listopada 2024) – kontekst SnappyBee/Deed RAT i Earth Estries. (www.trendmicro.com)
  4. CISA – „Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide” (3 września 2025) – zalecenia strategiczne dot. aktorów PRC. (CISA)
  5. Reuters – „AT&T, Verizon targeted by Salt Typhoon…” (29 grudnia 2024) – tło i skala kampanii na telekomy. (Reuters)

Google identyfikuje trzy nowe rodziny malware rosyjskiego COLDRIVER: NOROBOT, YESROBOT i MAYBEROBOT

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence Group (GTIG) ujawniła 20 października 2025 r. trzy powiązane ze sobą rodziny malware wykorzystywane przez rosyjską grupę COLDRIVER (znaną też jako Star Blizzard, Callisto, UNC4057): NOROBOT (downloader DLL), YESROBOT (backdoor w Pythonie) oraz MAYBEROBOT (implant PowerShell). Zidentyfikowany łańcuch infekcji stanowi ewolucję wcześniejszych kampanii z przynętą „ClickFix” i fałszywą weryfikacją CAPTCHA, których celem jest nakłonienie użytkownika do ręcznego uruchomienia złośliwego komponentu przez rundll32.exe.

W skrócie

  • COLDRIVER w ciągu 5 dni od publikacji analizy ich poprzedniego narzędzia (LOSTKEYS, maj 2025) wprowadził nowe „ROBOT-y”, znacząco zwiększając tempo rozwoju i modyfikacji TTP.
  • NOROBOT dostarcza kolejne etapy i przygotowuje środowisko; w najstarszych wariantach pobierał nawet pełną instalację Pythona 3.8 – artefakt głośny i łatwy do wykrycia.
  • YESROBOT to minimalny backdoor (Python/HTTPS, AES), zaobserwowany tylko dwukrotnie pod koniec maja 2025 r.; szybko go porzucono.
  • MAYBEROBOT (PowerShell) zastąpił YESROBOT: ma elastyczny protokół C2 i trzy komendy (pobierz/uruchom z URL, cmd.exe, blok PowerShell).
  • Zscaler śledzi część tego łańcucha jako BAITSWITCH (NOROBOT) i SIMPLEFIX (MAYBEROBOT); kampanie wykorzystywały przynęty ClickFix.

Kontekst / historia / powiązania

COLDRIVER od lat specjalizuje się w wyrafinowanym phishingu ukierunkowanym na NGO, think-tanki, doradców politycznych i dysydentów w krajach NATO. NCSC UK i CISA dokumentowały aktywność tej grupy jako Star Blizzard, przypisując jej operacje cyberszpiegowskie na rzecz interesów rosyjskich. W 2025 r. Google opisał LOSTKEYS – kradnący pliki stealer – oraz zwrot ku mechanice ClickFix, wcześniej obserwowanej m.in. przez Proofpoint również u aktorów państwowych.

Analiza techniczna / szczegóły luki

Wejście: ClickFix + CAPTCHA → rundll32.exe

  • Użytkownik trafia na stronę z fałszywą CAPTCHA (wariant przynęty COLDCOPY), która instruuje, by „zweryfikować człowieczeństwo” poprzez pobranie i uruchomienie DLL-a z użyciem rundll32.exe (np. plik „iamnotarobot.dll”, eksport humanCheck).

Etap 1: NOROBOT (downloader DLL)

  • Zadania: przygotowanie hosta, utrwalenie, pobranie kolejnych etapów z twardo zakodowanego C2.
  • Wczesny NOROBOT: dzielony klucz kryptograficzny (część w rejestrze, część w pliku), harmonogram zadań, pobieranie pełnego Python 3.8 i modułów (bitsadmin) – to prowadziło do YESROBOT.
  • Późniejsze NOROBOT: uproszczony łańcuch (logon script), rotacja infrastruktury/nazw plików/eksportów.

Etap 2a: YESROBOT (Python backdoor – szybko zarzucony)

  • C2 przez HTTPS, polecenia zaszyfrowane AES, identyfikacja hosta w nagłówku User-Agent. Minimalna funkcjonalność – każde polecenie musi być poprawnym kodem Python. Zaobserwowane dwa wdrożenia przez ~2 tygodnie w maju 2025 r.

Etap 2b: MAYBEROBOT (PowerShell implant – obecny standard)

  • Ciąg znaków C2, protokół obsługujący: (1) pobierz/uruchom z URL, (2) wykonaj polecenie przez cmd.exe, (3) wykonaj blok PowerShell; potwierdzenia i wyniki na osobnych ścieżkach. Bardziej elastyczny, bez potrzeby instalacji Pythona. W nomenklaturze Zscalera: SIMPLEFIX.

Nazewnictwo i powiązania

  • NOROBOT ≈ BAITSWITCH, MAYBEROBOT ≈ SIMPLEFIX (Zscaler ThreatLabz, IX–X 2025).

Praktyczne konsekwencje / ryzyko

  • Wzrost tempa operacji: szybkie przełączanie narzędzi po deanonimizacji (5 dni po publikacji LOSTKEYS) utrudnia detekcję opartą na wskaźnikach.
  • Technika ClickFix: socjotechnika wymuszająca manualne uruchomienie złośliwego kodu obchodzi wiele polityk kontroli skryptów i utrudnia klasyczne filtrowanie e-mail. Proofpoint raportował upowszechnienie ClickFix również u aktorów państwowych.
  • Priorytetyzacja celów: GTIG ocenia, że NOROBOT/MAYBEROBOT są zarezerwowane dla wysokowartościowych celów, być może już wcześniej wyłudzonych phishingiem (eskalacja z kradzieży kont do eksfiltracji z hosta).

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twardnienie stacji roboczych

  1. Zablokuj uruchamianie rundll32.exe z katalogów użytkownika / pobierania (WDAC/AppLocker, SRP), monitoruj nietypowe ścieżki DLL.
  2. Wymuś Constrained Language Mode/AMS podpisy w PowerShell, blokuj bitsadmin/curl/Invoke-WebRequest z niezaufanych kontekstów.
  3. Wdróż Attack Surface Reduction (ASR): blokowanie tworzenia zadań harmonogramu przez nieluźno zaufane procesy, ogranicz WMI i skrypty logon.
  4. Ogranicz instalacje Pythona na endpointach; wykrywaj nagłe pojawienie się katalogów typu %APPDATA%\Python38-64\. (artefakt wczesnego łańcucha).

Detekcja (przykładowe sygnały behawioralne)

  • Sekwencja: przeglądarka → pobranie DLL → rundll32.exe z parametrem exportu nietypowej nazwy (humanCheck) → komunikacja HTTPS do rzadkiej domeny/C2 → tworzenie zadania „System health check” → wywołanie Pythona/PowerShella.
  • Anomalia w User-Agent i nietypowe endpointy ACK/OUT w ścieżkach C2 (MAYBEROBOT).

Hunting / logi do korelacji

  • Sysmon: Event ID 1/7 (process/create), 3 (network), 11 (file create), 13 (registry), 19/20/21 (WMI), 24/25 (clipboard jeśli stosowane).
  • Windows Task Scheduler operational log (Microsoft-Windows-TaskScheduler/Operational) pod kątem nazwy „System health check”.

Szybkie playbooki reakcji

  • Izoluj host; zbierz scheduled tasks, klucze rejestru z przestrzeni HKCU\SOFTWARE\Classes.pietas (jeśli obecne), ślady bitsadmin.
  • Zastosuj blokadę wycieków (DLP) i tymczasową segmentację sieci dla kont wysokiego ryzyka.

Różnice / porównania z innymi przypadkami

  • LOSTKEYS (V1, maj 2025) vs ROBOT-y (X 2025): przejście od prostego stealera do elastycznych implantów operacyjnych (szczególnie PowerShell), rezygnacja z ciężkiego runtime (Python) na rzecz stealth.
  • ClickFix w 2025 r.: wcześniej kojarzony z cyberprzestępczością; od Q1–Q2 2025 r. Proofpoint dokumentuje jego adopcję przez aktorów państwowych (Rosja, Iran, Korea Płn.). COLDRIVER wpisuje się w ten trend.
  • Nazewnictwo: GTIG (NOROBOT/YESROBOT/MAYBEROBOT) vs Zscaler (BAITSWITCH/SIMPLEFIX) – to te same elementy łańcucha widziane z różnych etapów telemetrycznych.

Podsumowanie / kluczowe wnioski

COLDRIVER przyspieszył cykl eksponowanie → retooling → redeployment, co wymaga od obrońców skupienia się na behawioralnych wskaźnikach ataku (rundll32 z nietypowych lokalizacji, harmonogram, PowerShell C2), a nie wyłącznie na IOC. Elastyczny MAYBEROBOT oraz stale modyfikowany NOROBOT sugerują operacje precyzyjne przeciw celom wysokiej wartości, prawdopodobnie jako kolejny etap po udanym phishingu.

Źródła / bibliografia

  1. Google Cloud – To Be (A Robot) or Not to Be: New Malware Attributed to Russia State-Sponsored COLDRIVER (20.10.2025). (Google Cloud)
  2. Zscaler ThreatLabz – COLDRIVER Updates Arsenal with BAITSWITCH and SIMPLEFIX (24.09.2025). (Zscaler)
  3. Proofpoint – Around the World in 90 Days: State-Sponsored Actors Try ClickFix (17.04.2025). (Proofpoint)
  4. CISA / NCSC UK – Russian FSB cyber actor Star Blizzard continues worldwide spear-phishing campaigns (07.12.2023) — tło/atrybucja. (CISA)
  5. The Hacker News – Google Identifies Three New Russian Malware Families Created by COLDRIVER Hackers (21.10.2025). (The Hacker News)

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)

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)

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)