Archiwa: Windows - Strona 31 z 65 - Security Bez Tabu

Tag: Windows

Nowy ransomware Osiris: BYOVD z użyciem sterownika POORTRY i ślady powiązań z INC

Wprowadzenie do problemu / definicja luki

W styczniu 2026 r. badacze Symantec i Carbon Black Threat Hunter Team opisali nową rodzinę ransomware nazwaną Osiris, używaną w ukierunkowanym ataku na dużego operatora franczyz gastronomicznych w Azji Południowo-Wschodniej (incydent miał miejsce w listopadzie 2025).

Kluczowym elementem kampanii było rozbrojenie zabezpieczeń poprzez technikę BYOVD (Bring Your Own Vulnerable Driver) – w tym przypadku z użyciem sterownika POORTRY, który służy do eskalacji uprawnień i ubijania procesów bezpieczeństwa.

W skrócie

  • Nowa rodzina ransomware: Osiris to nowy szczep (bez potwierdzonych powiązań kodowych z dawnym „Osiris” z 2016 r.).
  • Model ataku: najpierw eksfiltracja danych (Rclone → Wasabi), potem szyfrowanie.
  • Evasion/EDR kill: sterownik POORTRY + narzędzie KillAV i zestaw narzędzi dual-use/LoTL.
  • Możliwe tropy do INC: zbieżności operacyjne (m.in. Wasabi i Mimikatz jako kaz.exe).

Kontekst / historia / powiązania

Nazwa „Osiris” może mylić: istniał ransomware o tej nazwie kojarzony z ekosystemem Locky (2016), ale Symantec podkreśla, że w obecnym przypadku nie ma przesłanek o powiązaniu między rodzinami.

Ciekawsze są natomiast powiązania taktyczne z grupą INC ransomware (Warble): w opisywanym incydencie zaobserwowano eksfiltrację do Wasabi buckets oraz użycie Mimikatz pod nazwą kaz.exe, co wcześniej wiązano z aktywnością INC.

Warto też pamiętać, że POORTRY (znany też jako BURNTCIGAR) ma historię użycia przez różne gangi ransomware i był rozwijany w sposób nastawiony na skuteczne „wyłączanie” EDR.

Analiza techniczna / szczegóły luki

1) Sekwencja działań (kill chain)

Z opisu incydentu wynika dość „klasyczny” schemat nowoczesnego ransomware, ale z mocnym naciskiem na obronę przed EDR:

  1. Wczesna aktywność i rekonesans + narzędzia dual-use/LoTL.
  2. Eksfiltracja danych: wykorzystanie Rclone do wysyłki do chmury Wasabi (kilka dni przed szyfrowaniem).
  3. Utrzymanie/zdalny dostęp: m.in. zmodyfikowany RustDesk (w kampanii opisywany jako wariant/instalacja „podszyta” pod legalne narzędzie).
  4. Neutralizacja zabezpieczeń: sterownik POORTRY (w kontekście BYOVD) oraz użycie KillAV i włączenie RDP jako kanału dostępu.
  5. Szyfrowanie + notatka okupu: pliki otrzymują rozszerzenie .Osiris, kasowane są migawki VSS.

2) POORTRY/BYOVD w praktyce

W klasycznym BYOVD atakujący „przynoszą” legalny, ale podatny sterownik i nadużywają jego funkcji do działań w jądrze. W tym przypadku Symantec zwraca uwagę, że POORTRY jest nietypowy, bo to sterownik „szyty” pod ubijanie narzędzi bezpieczeństwa, a nie tylko nadużycie cudzego podatnego drivera.

Dodatkowy kontekst daje Sophos: POORTRY to narzędzie rozwijane latami, a jego autorzy wykorzystywali luki/kruczki procesu zaufania do podpisywania sterowników (w praktyce: gra na granicy zaufania do podpisów, łańcuchów i wyjątków zgodności).

3) Funkcje ransomware Osiris

Symantec opisuje Osiris jako „pełnoprawny” payload ransomware z typowymi funkcjami: zatrzymywanie usług, ubijanie procesów, selektywne szyfrowanie katalogów/rozszerzeń i zrzut notatki okupu.

Istotne detale operacyjne:

  • Osiris ma tryby szyfrowania (m.in. częściowe vs pełne) oraz opcje związane z środowiskami wirtualizacji (Hyper-V).
  • Ma zdefiniowane listy pomijanych rozszerzeń i folderów systemowych, co ogranicza ryzyko „zabicia” systemu zanim skończy się szyfrowanie.
  • Zastosowano hybrydowy schemat kryptograficzny i unikalny klucz per plik; w doniesieniach medialnych doprecyzowano połączenie mechanizmów krzywych eliptycznych z AES-128-CTR oraz optymalizacje wydajnościowe (async I/O).

Praktyczne konsekwencje / ryzyko

  1. Podwójne wymuszenie (double extortion): skoro dane są kradzione przed szyfrowaniem (Rclone → Wasabi), sama odbudowa z kopii może nie zamknąć incydentu — ryzyko wycieku i presji negocjacyjnej zostaje.
  2. EDR pod ostrzałem: użycie sterownika w jądrze do wyłączania ochrony znacząco zwiększa skuteczność ransomware i skraca czas „od wykrycia do szyfrowania”.
  3. Ryzyko powtórzeń TTP: jeśli to faktycznie ewolucja/odprysk ekosystemu INC (albo naśladownictwo), zespoły IR mogą spodziewać się podobnych wzorców: eksfiltracja do Wasabi, kaz.exe, zestaw narzędzi sieciowych i zdalnego dostępu.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  • Polowanie na Rclone: uruchomienia, zadania zaplanowane, nietypowe transfery do chmury oraz artefakty konfiguracji (szczególnie kierunek: Wasabi).
  • Telemetria sterowników: korelacja zdarzeń ładowania driverów + alerty na nietypowe/podejrzane sterowniki w środowisku (w tym POORTRY).
  • Hunting na „kaz.exe” i narzędzia dual-use: wykrywanie nietypowych uruchomień Mimikatz/LSASS access oraz narzędzi rozpoznania i lateral movement (w raporcie wymieniono m.in. Netscan/Netexec/MeshAgent).
  • Weryfikacja RustDesk: jeśli w organizacji jest dopuszczony, sprawdzić integralność i łańcuch dostarczenia; jeśli nie jest dopuszczony — potraktować jako IOC/TTP do eskalacji.

Utwardzanie (1–4 tygodnie)

  • Kontrola sterowników (Windows): polityki ograniczające ładowanie sterowników, tam gdzie możliwe włączanie mechanizmów typu HVCI/Memory Integrity i egzekwowanie zasad podpisu (w praktyce: minimalizacja powierzchni BYOVD). (Kontekst ryzyka i obejść pokazuje analiza Sophos).
  • Ograniczenie RDP: w raporcie wskazano, że RDP zostało włączone w środowisku ofiary — warto egzekwować „deny by default”, MFA, jump hosty i segmentację.
  • Segmentacja i egress control: ransomware, które eksfiltruje dane do chmury, bardzo korzysta z braku kontroli wyjścia. Ogranicz egress do „known good” i monitoruj nowe destynacje.
  • Odporność na kasowanie VSS: kopie zapasowe offline/immutability, testy odtwarzania i ochrona repozytoriów backupu (Osiris usuwa migawki).

Różnice / porównania z innymi przypadkami

  • Osiris 2025/2026 vs „Osiris” 2016 (Locky): zbieżna nazwa, ale Symantec nie widzi związku rodzinnego — to ważne, bo inaczej wyglądałby proces triage (IOC, logika szyfrowania, negocjacje, dekryptory).
  • BYOVD „klasyczne” vs POORTRY: w wielu kampaniach BYOVD nadużywa się legalnych podatnych driverów; tutaj istotny jest komponent „EDR killer” rozwijany jako własny ekosystem (co podnosi poprzeczkę dla obrony).
  • Podobieństwa do INC: wspólne „smaczki” (Wasabi, kaz.exe) mogą oznaczać: (a) kopiowanie TTP, (b) migrację afilianta, (c) współdzielenie playbooków. W praktyce dla obrony różnica jest mniejsza niż dla atrybucji — liczy się dopasowanie detekcji do TTP.

Podsumowanie / kluczowe wnioski

Osiris wygląda na nowy, dojrzały operacyjnie ransomware, wdrażany przez sprawnych napastników: najpierw kradzież danych, potem szyfrowanie, a po drodze agresywne „zdejmowanie” zabezpieczeń przez komponenty jądra (POORTRY/BYOVD).

Dla SOC/IR najważniejsze są trzy obszary: kontrola egress i polowanie na eksfiltrację (Rclone/Wasabi), telemetria sterowników i próby wyłączania EDR, oraz wczesne wykrywanie narzędzi dual-use używanych do rekonesansu i ruchu bocznego.

Źródła / bibliografia

  • The Hacker News — „New Osiris Ransomware Emerges as New Strain Using POORTRY Driver in BYOVD Attack” (22.01.2026). (The Hacker News)
  • SECURITY.COM (Symantec/Broadcom) — „Osiris: New Ransomware, Experienced Attackers?” (22.01.2026). (security.com)
  • Sophos — „Attack tool update impairs Windows computers” (27.08.2024) – kontekst POORTRY/BURNTCIGAR. (news.sophos.com)
  • SiliconANGLE — opis kampanii i uzupełniające szczegóły techniczne (22.01.2026). (SiliconANGLE)

KONNI wykorzystuje AI do budowy backdoora w PowerShell i celuje w deweloperów (blockchain/crypto)

Wprowadzenie do problemu / definicja luki

W styczniu 2026 Check Point Research opisał aktywną kampanię phishingową przypisywaną do KONNI – północnokoreańskiego aktora działającego co najmniej od 2014 roku. Tym razem kluczową zmianą jest dobór ofiar (software development/engineering) oraz narzędzie egzekucji: backdoor w PowerShell, którego cechy wskazują na AI-assist/AI-generated development (nie tyle nowe TTP, co szybsze i „czyściejsze” wytwarzanie kodu z typowymi artefaktami LLM).

W praktyce nie jest to „pojedyncza luka CVE”, ale łańcuch infekcji oparty o socjotechnikę, pliki skrótów Windows (LNK) i wieloetapowe uruchomienie komponentów, którego efektem jest trwały dostęp do hosta oraz możliwość dalszej eskalacji do narzędzi zdalnego zarządzania.

W skrócie

  • Kampania celuje w deweloperów i zespoły inżynieryjne z dostępem do zasobów blockchain/crypto (repozytoria, API, portfele, infrastruktura).
  • Start łańcucha: link hostowany na Discord → pobranie ZIP z przynętą (PDF) i LNK, który uruchamia loader PowerShell i rozpakowuje kolejne elementy (DOCX + CAB).
  • Utrwalenie: Scheduled Task podszywający się pod OneDrive, uruchamiany cyklicznie, deszyfrujący (XOR) i wykonujący backdoor „in-memory”.
  • Backdoor zawiera rozbudowane anti-analysis (progi sprzętowe, blacklist narzędzi, wymaganie aktywności myszą), fingerprinting przez WMI oraz mechanizmy eskalacji UAC (fodhelper).
  • C2: obejście „bramki” po stronie serwera przez emulację JavaScript challenge i pozyskanie cookie __test, a potem cykliczne wysyłanie metadanych hosta do endpointu PHP.

Kontekst / historia / powiązania

KONNI historycznie kojarzono głównie z celami w Korei Południowej (dyplomacja, rząd, NGO, akademia) oraz klasycznym spear-phishingiem opartym o tematy geopolityczne. W opisywanej kampanii widać przesunięcie na ekosystemy techniczne: development i obszary, gdzie pojedynczy kompromitowany endpoint może otworzyć drogę do kontenerów, CI/CD, sekretów w repozytoriach czy kluczy do usług.

Z szerszej perspektywy to pasuje do obserwacji, że północnokoreański program cyber jest wykorzystywany nie tylko do szpiegostwa, ale również do operacji generujących środki finansowe, m.in. przez kradzieże kryptowalut i naruszenia sankcji.

Analiza techniczna / szczegóły luki

1) Przynęty i initial access

Przynęty wyglądają jak materiały projektowe (architektura, stack, harmonogramy, budżety/milestones) powiązane z blockchain/crypto. Wektor początkowy wprost nie jest ujawniony, ale łańcuch startuje od linku hostowanego na Discord, prowadzącego do archiwum ZIP.

Z perspektywy MITRE ATT&CK to klasyczny przypadek User Execution: Malicious File (T1204.002) – ofiara musi otworzyć/uruchomić spreparowany plik (tu: LNK).

2) Łańcuch infekcji (ZIP → LNK → CAB → BAT/PS1)

W ZIP znajdują się PDF (lure) oraz LNK. LNK uruchamia osadzony loader PowerShell, który:

  • zapisuje na dysk przynętę DOCX i archiwum CAB (oba osadzone w LNK i XOR-owane jednobajtowym kluczem),
  • otwiera DOCX, żeby odciągnąć uwagę,
  • rozpakowuje CAB, gdzie znajdują się: PowerShell backdoor, dwa batch file oraz exe do UAC bypass,
  • uruchamia pierwszy batch.

3) Persistence i „living off the land”

Pierwszy batch tworzy staging w C:\ProgramData, przenosi komponenty i zakłada Scheduled Task podszywający się pod zadanie OneDrive uruchamiane co godzinę. Zadanie czyta zaszyfrowany backdoor, wykonuje XOR-decrypt (klucz ‘Q’) i uruchamia kod w pamięci. Następnie batch usuwa się z dysku (redukcja śladów).

4) Cechy sugerujące AI-generated backdoor

CPR wskazuje na nietypowo „produktowy” charakter skryptu: czytelna struktura, komentarze/dokumentacja oraz artefakt wprost przypominający placeholder z generatorów LLM: komentarz w rodzaju „your permanent project UUID” (instrukcja dla człowieka jak uzupełnić wartość). To zestaw sygnałów, który ma wspierać tezę o AI-assist/AI-generated development.

5) Funkcje backdoora: anti-analysis, identyfikacja hosta, eskalacja

Backdoor wykonuje:

  • anti-analysis/sandbox evasion: progi sprzętowe, wykrywanie narzędzi (IDA, Wireshark, Procmon itd.), wymaganie interakcji użytkownika (ruch/kliknięcia myszy),
  • single-instance przez mutex Global\SysInfoProject_<projectUUID> (UUID stały dla próbek wskazanych w raporcie),
  • fingerprinting przez WMI (m.in. serial płyty głównej + UUID systemu), SHA-256 i skrócenie do 16 znaków,
  • rozgałęzienie działań wg uprawnień: dla „User” – fodhelper UAC bypass przez manipulacje w HKCU\Software\Classes i przekierowanie protokołu ms-settings, a następnie modyfikację ConsentPromptBehaviorAdmin (de facto ograniczenie promptów UAC dla adminów).

Dodatkowo, w scenariuszu „Admin” raport opisuje m.in. dodanie wykluczenia Windows Defender dla C:\ProgramData i podmianę zadania harmonogramu na wersję z wyższym kontekstem uprawnień.

6) C2 i obejście „bramki” anty-bot

C2 jest zabezpieczone client-side’ową „bramką” (AES/JS) i cookie __test. Backdoor emuluje JavaScript challenge: pobiera implementację AES używaną przez stronę, odtwarza logikę JS, odszyfrowuje ciphertext z serwera i wyciąga token, a następnie używa go jako cookie do kolejnych żądań. Potem okresowo wysyła metadane hosta (ID, poziom uprawnień, IPv4, username) do endpointu PHP, a odpowiedzi traktuje jako tasking (PowerShell wykonywany w tle).

7) Warianty i IoC

CPR wspomina też o wariancie z października 2025, gdzie początkowy payload był wprost obfuskowanym skryptem PowerShell pobierającym kolejne komponenty, a OneDriveUpdater.exe służył głównie do pobrania i uruchomienia klienta SimpleHelp (legit RMM) dla interaktywnego dostępu.

W raporcie podano też przykładowe domeny/IP C2 oraz listy hashy (IoC).

Praktyczne konsekwencje / ryzyko

Dla organizacji software’owych i zespołów blockchain/crypto ryzyko jest szczególne, bo kompromitacja jednego stanowiska developerskiego może przełożyć się na:

  • wyciek sekretów z repozytoriów (tokeny do Git, klucze API, SSH),
  • przejęcie CI/CD (wstrzyknięcia w pipeline, supply-chain),
  • dostęp do środowisk chmurowych i walletów/kluczy podpisujących,
  • lateral movement do zasobów produkcyjnych.

Kontekst finansowy jest istotny: w oficjalnych opracowaniach dot. aktywności DPRK podkreśla się skalę cyber-kradzieży i ich rolę w finansowaniu działań państwa, w tym obchodzeniu sankcji.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  1. Zablokuj/ogranicz uruchamianie LNK z pobranych archiwów i katalogów typu Downloads/Temp (tam, gdzie to możliwe politykami). To bezpośrednio tnie klasę ataków „malicious file + user execution”.
  2. Polowanie na Scheduled Tasks podszywające się pod OneDrive i uruchamiające inline PowerShell (szczególnie z odczytem bajtów z C:\ProgramData\… i natychmiastowym IEX).
  3. Telemetria EDR: alerty na PowerShell obfuskowany arytmetyką, nietypowe tworzenie słowników stringów + Invoke-Expression.
  4. Wykrywanie zmian w rejestrze pod fodhelper UAC bypass (ścieżki pod HKCU\Software\Classes i ms-settings) oraz modyfikacji ConsentPromptBehaviorAdmin.
  5. Network: blokady/alerty na wskazane w raporcie domeny/IP oraz na nietypowe żądania do endpointów PHP po wcześniejszym „handshake” z cookie __test.

Średni termin (1–4 tygodnie)

  • Hardening stacji dev: separacja kont, MFA wszędzie, minimalizacja lokalnych uprawnień admin, izolacja sekretów (vault), rotacja tokenów.
  • Ograniczenie możliwości dodawania Defender exclusions i monitorowanie wykluczeń dla C:\ProgramData.
  • Kontrole supply-chain: podpisywanie artefaktów, wymuszenie code review dla zmian w pipeline, zasada „two-person rule” dla kluczy produkcyjnych.
  • Uświadamianie: „projektowe PDF/DOCX z Discorda” jako realna przynęta dla devów – to dziś równie typowe jak „faktura” w klasycznych kampaniach.

Różnice / porównania z innymi przypadkami

  • KONNI (AI-assist backdoor): raportowane elementy wskazują na wykorzystanie AI głównie do wytwarzania/formatowania kodu (komentarze-artefakty, modularność), przy zachowaniu znanych TTP (LNK, scheduled task, PowerShell).
  • Szerszy trend AI-generated malware: Check Point kilka dni wcześniej opisał „VoidLink” jako przykład bardziej „frameworkowego” podejścia, gdzie AI miało przyspieszać nie tylko pisanie kodu, ale też planowanie i iterację całego projektu. To sugeruje, że „AI w malware” szybko przesuwa się od ciekawostek do realnego przyspieszacza R&D po stronie atakujących.
  • LNK jako stały motyw: niezależnie od tej konkretnej kampanii, analizy TTP w regionie (w tym porównania aktorów państwowych) pokazują, że pliki LNK w archiwach ZIP są dojrzałym i powtarzalnym wzorcem initial access.

Podsumowanie / kluczowe wnioski

  1. KONNI rozszerza profil ofiar: deweloperzy + blockchain/crypto to atrakcyjny cel, bo daje dostęp do sekretów i infrastruktury o wysokiej wartości.
  2. Największa nowość nie leży w „magicznych” nowych technikach, tylko w tym, że AI może obniżać koszt i czas tworzenia użytecznych implantów (bardziej uporządkowany kod, szybkie wariantowanie).
  3. Obrona powinna iść dwutorowo: (a) twarde kontrole uruchamiania plików i PowerShell, (b) security hygiene w środowisku dev (sekrety, pipeline, uprawnienia).
  4. Warto traktować kanały typu Discord jako realny wektor dystrybucji „materiałów projektowych” – szczególnie w społecznościach dev/web3.

Źródła / bibliografia

  1. Check Point Research – KONNI Adopts AI to Generate PowerShell Backdoors (22 stycznia 2026). (Check Point Research)
  2. MITRE ATT&CK – User Execution: Malicious File (T1204.002). (attack.mitre.org)
  3. Genians – analiza spear-phishing i nadużyć LNK/ZIP w kampaniach APT (kontekst TTP). (genians.co.kr)
  4. MOFA Japan (PDF) – raport dot. naruszeń/obchodzenia sankcji i roli DPRK cyber (kontekst finansowy).
  5. Check Point – VoidLink Signals the Start of a New Era in AI-Generated Malware (19 stycznia 2026). (Check Point Blog)

VoidLink: cloud-native framework malware dla Linuksa, który (prawdopodobnie) powstał „prawie w całości” z pomocą AI

Wprowadzenie do problemu / definicja zagrożenia

VoidLink to zaawansowany, „cloud-first” framework malware dla Linuksa zaprojektowany pod długotrwały, dyskretny dostęp do środowisk chmurowych i kontenerowych (Kubernetes/Docker). Z perspektywy obrońców najważniejsze jest to, że nie wygląda jak typowy „jednofunkcyjny trojan” – bardziej przypomina kompletne C2/post-exploitation narzędzie z loaderami, implantami, mechanizmami rootkit oraz rozbudowanym systemem wtyczek.

W styczniu 2026 temat zyskał dodatkowy ciężar: Check Point Research wskazuje na rzadko spotykane dowody sugerujące, że znacząca część rozwoju VoidLink mogła zostać wykonana w trybie „AI-driven development” (agent + specyfikacje + sprinty), co radykalnie skraca czas tworzenia złożonych narzędzi ofensywnych.

W skrócie

  • Cel i środowisko: Linux w chmurze i kontenerach; rozpoznawanie dostawcy chmury oraz kontekstu (K8s/Docker) i dopasowanie zachowania.
  • Architektura: loader 2-etapowy + implant + in-memory plugin system (ponad 30 modułów; panel wskazywał ok. 37 wtyczek).
  • Stealth i rootkity: LD_PRELOAD / LKM / eBPF – wybór techniki zależny od wersji kernela i „postury” środowiska.
  • C2/łączność: wiele kanałów (m.in. HTTP/HTTPS, DNS, ICMP) oraz mechanizmy kamuflażu ruchu; w próbkach widać też kierunek „mesh/P2P”.
  • AI w wytwarzaniu: Check Point opisuje metodykę SDD (Spec Driven Development) i artefakty po narzędziu TRAE SOLO; THN i Sysdig przytaczają dodatkowe sygnały „LLM-owego” boilerplate’u.
  • Status: brak potwierdzonych infekcji „w realu” w momencie publikacji analiz; wygląda na projekt w fazie intensywnego rozwoju.

Kontekst / historia / powiązania

  • Wykrycie: Check Point Research trafił na próbki w grudniu 2025; część binariów zawierała artefakty developerskie (np. symbole debug), co sugerowało buildy „w trakcie” a nie masowo wdrożone malware.
  • Atrybucja (ostrożnie): w raportach pojawia się wątek środowiska developerskiego powiązanego językowo/operacyjnie z Chinami, ale bez twardego przypisania do konkretnej grupy.
  • Tempo rozwoju: Check Point wskazuje, że narzędzie urosło do ~88 tys. linii kodu do początku grudnia 2025; THN podkreśla „pierwszy funkcjonalny implant” w czasie krótszym niż tydzień.
  • „Wgląd w warsztat”: kluczowe w tej historii jest to, że badacze mieli wyjątkowy wgląd w artefakty planowania i budowy (m.in. przez błędy OPSEC autora i wyciek plików).

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy „tradecraftu” VoidLink, z perspektywy obrony chmury i Linuksa.

1) Cloud-first rozpoznanie i działania w kontenerach

VoidLink potrafi identyfikować popularnych dostawców chmury (m.in. AWS, Azure, GCP, Alibaba, Tencent) i pobierać dane z mechanizmów metadata/instancji. Dodatkowo wykrywa, czy działa w Dockerze lub w podzie Kubernetes, a następnie dobiera moduły post-exploitation (np. pod kątem eksfiltracji sekretów, prób „container escape”, ruchu lateralnego).

2) Modularność: Plugin API inspirowane Cobalt Strike

Check Point opisuje architekturę z własnym Plugin API inspirowanym podejściem Beacon Object Files (BOF). Wtyczki są ładowane w runtime i wykonywane in-memory, co sprzyja „cichym” operacjom i ogranicza artefakty na dysku. Kategorie modułów obejmują m.in. recon, cloud/container, credential harvesting, persistence, anti-forensics, lateral movement.

3) Rootkity i ukrywanie: LD_PRELOAD, LKM oraz eBPF

VoidLink ma „rootkit-style capabilities” w kilku wariantach:

  • LD_PRELOAD (user-mode hooking),
  • LKM (kernel module),
  • eBPF (hooking ścieżek w sposób lepiej dopasowany do nowszych, „utwardzonych” systemów).

Mechanizm doboru techniki zależy od kernela i dostępnych funkcji; celem jest m.in. ukrywanie procesów, plików i socketów, a także maskowanie samych komponentów.

4) C2 i kamuflaż ruchu

VoidLink obsługuje wiele transportów (HTTP/1.1, HTTP/2, WebSocket, DNS, ICMP) oraz warstwy kamuflażu (udawanie „legitnego” ruchu, pakowanie danych w obiekty przypominające treści webowe/grafiki itp.). W kodzie widać też kierunek rozwoju w stronę mesh/P2P.

5) Adaptive stealth i OPSEC: „ryzyko” środowiska wpływa na zachowanie

Jedna z mocniejszych cech: po starcie malware ma enumerować zabezpieczenia (np. EDR/hardening), wyliczać risk score i na tej podstawie modyfikować agresywność działań (np. wolniejsze skanowanie w środowisku monitorowanym). Do tego dochodzą: runtime code encryption, mechanizmy anty-debug, integralność runtime oraz self-deletion przy wykryciu manipulacji.

6) „Server-Side Rootkit Compilation” (Sysdig)

Sysdig zwraca uwagę na element, który rozwiązuje klasyczny problem LKM rootkitów: portowalność względem wersji kernela. Według analizy, serwer C2 ma budować moduły kernela „na żądanie” pod konkretną wersję kernela ofiary (SRC). To może znacząco podnieść skuteczność w heterogenicznych flotach linuksowych w chmurze.

Praktyczne konsekwencje / ryzyko

Dla większości organizacji ryzyko nie sprowadza się do „jeszcze jednego malware”, tylko do możliwego przejęcia warstwy sterującej chmurą:

  • Kradzież poświadczeń i sekretów (cloud creds, tokeny, klucze, dane do repozytoriów/SCM typu Git) → ryzyko kompromitacji CI/CD, „secrets sprawl” i dostępu do kodu.
  • Trwała obecność w klastrach i node’ach dzięki persistence + ukrywaniu (rootkit/eBPF/LKM) oraz adaptacji do monitoringu.
  • Cichy post-exploitation w K8s/Docker (recon, eskalacje, potencjalne ucieczki z kontenera) → dostęp do workloadów i danych.
  • Zmiana ekonomii ataku dzięki AI: jeśli Check Point ma rację, bariera wejścia dla budowy „pełnego frameworka” spada – pojedynczy actor może iterować szybciej, niż zespoły defensywne aktualizują detekcje i polityki.

Jednocześnie warto trzymać w głowie fakt, że w analizach na styczeń 2026 nie ma potwierdzonych, masowych infekcji w środowiskach produkcyjnych – ale projekt wygląda jak „prawie gotowy” ekosystem C2.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają sens nawet wtedy, gdy VoidLink nie jest (jeszcze) „w wild”.

1) Detekcja runtime dla Linuksa i kontenerów

  • Postaw na runtime monitoring (syscall/activity-based), bo część technik jest „fileless” lub ukrywa artefakty na dysku. Sysdig podkreśla, że mimo zaawansowania zachowania na poziomie syscalls są widoczne dla narzędzi klasy runtime (np. Falco).
  • W K8s: reguły na nietypowe exec w kontenerach, dostęp do socketów dockera, nietypowe mounty, operacje na /proc, manipulacje BPF, ładowanie modułów kernela.

2) Ograniczenie „blast radius” w chmurze

  • Przejrzyj IAM: minimalne uprawnienia, krótkie TTL tokenów, rotacja kluczy, rozdzielenie ról CI/CD i adminów.
  • Uszczelnij dostęp do instance metadata (IMDS/metadata proxy), bo VoidLink aktywnie pyta o dane środowiska chmurowego.
  • Zredukuj ekspozycję sekretów: używaj menedżerów sekretów (i audytuj, gdzie lądują w env/args).

3) Twarde kontrole na hoście

  • Rozważ ograniczenia dla eBPF i ładowania modułów (tam, gdzie to możliwe operacyjnie).
  • Hardening: kontrola integralności, ograniczenie narzędzi developerskich na serwerach produkcyjnych, monitoring zmian w usługach/systemd/cron (persistence).

4) Kontrola egress i anomalii C2

  • Monitoruj/ogranicz: DNS tunneling, nietypowe ICMP, WebSocket/HTTP2 do nieznanych destynacji. VoidLink ma wiele kanałów C2 i kamuflaż ruchu, więc „allow-all egress” w chmurze to proszenie się o kłopoty.

5) Przygotuj proces IR „pod cloud-native”

  • Playbook na incydent w K8s (izolacja node/pod, snapshoty, artefakty runtime, eksport audit logs).
  • Zbieraj dane, które przetrwają anti-forensics (telemetria runtime, logi z warstwy kontrolnej chmury).

Różnice / porównania z innymi przypadkami

  • VoidLink vs „klasyczne Linux malware”: tu mamy platformę C2 + post-exploitation z pluginami, dashboardem operatorskim i adaptacją do cloud/K8s – to bardziej „Linuxowy odpowiednik” ekosystemów znanych z Windows.
  • Inspiracje Cobalt Strike: podobieństwo jest jawne w warstwie API/wtyczek (BOF-like). To ważne, bo pokazuje przenoszenie sprawdzonych wzorców ofensywnych do chmury opartej o Linuksa.
  • AI-assisted malware (nowa jakość): Check Point argumentuje, że wcześniejsze „AI malware” bywało niskiej jakości lub wtórne, a VoidLink ma być pierwszym dobrze udokumentowanym przypadkiem, gdzie AI przyspieszyło budowę złożonego, oryginalnego frameworka przy udziale kompetentnego twórcy.

Podsumowanie / kluczowe wnioski

VoidLink to sygnał ostrzegawczy w dwóch wymiarach: (1) technicznie – bo łączy cloud awareness, pluginową architekturę i rootkity (LD_PRELOAD/LKM/eBPF) z wielokanałowym C2; (2) metodycznie – bo według Check Point znacząca część wytwarzania mogła być „napędzana” przez podejście agentowe (SDD + sprinty + automatyzacja), co skraca cykl tworzenia ofensywnych platform.

Dobra wiadomość: w momencie publikacji analiz (styczeń 2026) nie ma twardych dowodów na szerokie użycie w atakach. Zła: projekt wygląda jak „prawie gotowy” i może zostać szybko dopięty do kampanii szpiegowskich, kradzieży sekretów w chmurze lub działań supply-chain.

Źródła / bibliografia

  1. Check Point Research – „Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework” (13.01.2026). (Check Point Research)
  2. Sysdig Threat Research – „VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits” (16.01.2026). (sysdig.com)
  3. Check Point Research – „VoidLink: Evidence That the Era of Advanced AI-Generated Malware Has Begun” (20.01.2026). (Check Point Research)
  4. The Hacker News – „VoidLink Linux Malware Framework Built with AI Assistance Reaches 88,000 Lines of Code” (21.01.2026). (The Hacker News)
  5. SecurityWeek – „VoidLink Linux Malware Framework Targets Cloud Environments” (15.01.2026). (SecurityWeek)

Korea Północna i „Contagious Interview”: jak złośliwe projekty VS Code uruchamiają malware przez tasks.json

Wprowadzenie do problemu / definicja luki

Kampania powiązana z aktorami DPRK (Korea Północna), znana jako Contagious Interview, ewoluuje w stronę ataków „zero-click-ish” z perspektywy programisty: ofiara nie musi świadomie uruchamiać malware, wystarczy że sklonuje repo i otworzy je w Visual Studio Code. Najnowszy wariant wykorzystuje mechanizm VS Code Tasks (.vscode/tasks.json) do automatycznego wykonania poleceń po otwarciu folderu projektu, prowadząc do instalacji backdoora z funkcjami zdalnego wykonania kodu.

Kluczowe w tym łańcuchu jest zachowanie użytkownika: VS Code pyta o zaufanie do repozytorium (Workspace Trust), a udzielenie zaufania może uruchomić przetwarzanie zadań i wykonanie osadzonych komend.

W skrócie

  • APT powiązany z DPRK podszywa się pod rekruterów/CTO i dostarcza „zadania rekrutacyjne” jako repozytoria Git.
  • Repo zawiera .vscode/tasks.json z runOptions.runOn: "folderOpen", co pozwala na uruchomienie zadania przy otwarciu projektu (po zgodzie na automatyczne taski).
  • W obserwacjach Jamf na macOS dochodziło do uruchomienia w tle polecenia pobierającego zdalny JavaScript (hostowany m.in. na Vercel) i „wpinającego” go bezpośrednio do Node.js (pipe), co realizuje backdoora i pętlę beaconingu.
  • Kampania wykorzystuje i rozwija rodziny malware powiązane z Contagious Interview: BeaverTail (warstwa Node/infostealer/downloader) i InvisibleFerret (backdoor, często Python).

Kontekst / historia / powiązania

Contagious Interview jest śledzona od co najmniej 2023 r. jako kampania nastawiona na programistów i osoby szukające pracy w branży tech. Unit 42 opisywał scenariusze, w których fałszywi rekruterzy nakłaniali ofiary do instalacji/uruchomienia „aplikacji” (np. podszywających się pod narzędzia do rozmów), co prowadziło do infekcji BeaverTail oraz finalnie InvisibleFerret.

W styczniu 2026 r. obserwujemy przesunięcie ciężaru z „uruchom plik” na „otwórz repo w IDE”: socjotechnika pozostaje podobna (LinkedIn, zadanie techniczne, code review), ale technika wykonania payloadu coraz mocniej wpasowuje się w domyślne workflow deweloperskie.

Analiza techniczna / szczegóły luki

1) Mechanizm: VS Code Tasks + runOn: folderOpen

VS Code pozwala definiować zadania w .vscode/tasks.json. Dokumentacja opisuje runOptions.runOn, gdzie folderOpen oznacza uruchomienie taska przy otwarciu folderu. Co ważne: przy pierwszym otwarciu folderu z takim taskiem użytkownik dostaje pytanie, czy zezwolić na automatyczne uruchamianie zadań w tym folderze.

W praktyce atakujący:

  • ukrywa złośliwy task wśród „normalnych” zadań (np. udających lint/build),
  • ustawia runOn: "folderOpen",
  • dobiera komendę tak, aby wyglądała niegroźnie (np. uruchomienie pliku udającego font), ale w rzeczywistości wykonywała kod (np. node ...).

2) Punkt krytyczny: Workspace Trust

Jamf wskazuje, że przy otwarciu projektu VS Code pyta o zaufanie do autora repozytorium, a po jego udzieleniu aplikacja może automatycznie przetwarzać tasks.json, co „otwiera drzwi” do wykonania arbitralnych poleceń osadzonych w taskach.

3) Łańcuch infekcji obserwowany przez Jamf (macOS)

W badanym wariancie na macOS uruchamiane było polecenie w tle (m.in. z nohup bash -c), które pobierało zdalny JavaScript i przekazywało go bezpośrednio do runtime Node.js. Payload (hostowany na infrastrukturze typu vercel.app) implementował logikę backdoora: rozpoznanie hosta, utrzymywanie pętli wykonywania, komunikacja z serwerem i możliwość zdalnego wykonania kodu.

4) „Dual-stack” i dodatkowe wektory (wg Security Alliance)

Security Alliance opisuje architekturę „dual-stack”:

  • warstwa Node.js: szybka kradzież danych (m.in. klucze, screeny, pliki, przeglądarki) i uruchomienie kanału zdalnego sterowania,
  • warstwa Python: komponenty długotrwałe, w tym kradzież portfeli i elementy monetizacji (np. mining).

W raporcie pojawiają się też warianty awaryjne: jeśli wektor VS Code nie zadziała, malware może „zahaczać” o logikę aplikacji (uruchomi się dopiero przy starcie projektu) lub próbować dociągnąć złośliwą zależność npm.

Praktyczne konsekwencje / ryzyko

Dlaczego to groźne dla organizacji, nie tylko dla kandydatów?

  • Programista często pracuje na urządzeniu z dostępem do repozytoriów firmowych, sekretów CI/CD, tokenów chmurowych, kluczy SSH i portfeli kryptowalutowych (szczególnie w fintech/crypto).
  • Atak może zadziałać nawet wtedy, gdy ofiara „tylko zerknie na kod” lub pozwoli narzędziu AI przeanalizować repo (bo w tle uruchamia się task/Trusted Workspace).
  • Skutki obejmują: przejęcia kont, exfiltrację IP/source code, kradzież środków, a także lateral movement do środowisk firmowych.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów developerskich (natychmiast)

  1. Nie ufaj repo „z rekrutacji” domyślnie: jeśli VS Code pyta o Workspace Trust — traktuj to jak prompt bezpieczeństwa (tak jak ostrzeżenie o makrach).
  2. Przeglądaj .vscode/tasks.json zanim otworzysz projekt
    • Szukaj runOptions + runOn: "folderOpen" oraz zadań o mylących nazwach (lint, eslint-check, build).
  3. Otwieraj nieznane repo w izolacji: VM / kontener / osobny profil użytkownika bez dostępów do firmowych sekretów (kluczy SSH, tokenów chmurowych). (To wynika bezpośrednio z wektorów i celów kampanii opisanych w źródłach.)
  4. Polityka zależności: instaluj pakiety npm tylko z weryfikowanych źródeł i unikaj „npm install” na niezweryfikowanych repozytoriach.

Dla SOC / Blue Team (detekcja i hunting)

  • Telemetria procesów: wzorce typu bash -c ... curl ... | node, nietypowe uruchomienia Node przy otwieraniu folderu w VS Code, oraz procesy potomne VS Code uruchamiające shell.
  • Polowanie po artefaktach: nietypowe pliki w .vscode/, zadania z runOn: folderOpen, podejrzane „zasoby” udające fonty uruchamiane przez node.
  • Egress/IOC: podwyższona czujność na krótkotrwałe domeny/hosting używany do stagingu payloadów (w obserwacjach pojawia się Vercel).

Różnice / porównania z innymi przypadkami

  • Wcześniej (2023–2024): częsty schemat to nakłonienie ofiary do instalacji/uruchomienia „aplikacji” lub kodu w ramach rozmowy rekrutacyjnej; BeaverTail i InvisibleFerret były rozwijane i przenoszone między platformami (macOS/Windows).
  • Teraz (2025–2026): nacisk przesuwa się na łańcuch dostawy przez repozytoria i IDE — otwarcie folderu w VS Code może uruchomić złośliwy task (folderOpen), a dodatkowe wektory (hook w runtime aplikacji, zależności npm) zwiększają „odporność” ataku na niepowodzenie jednego sposobu.

Podsumowanie / kluczowe wnioski

  • Mechanizmy automatyzacji w IDE (Tasks) są funkcją produktywności, ale w rękach APT stają się wektorem initial access — szczególnie gdy łączą się z socjotechniką „zadania rekrutacyjnego”.
  • Największe ryzyko wynika z „małego” kliknięcia: Workspace Trust i zgoda na automatyczne taski.
  • Organizacje powinny traktować nieznane repozytoria jak nieznane załączniki: izolacja, przegląd przed uruchomieniem, polityki zależności i telemetryka procesów.

Źródła / bibliografia

  1. The Hacker News – opis kampanii i najnowszego wariantu z VS Code Tasks (20 stycznia 2026). (The Hacker News)
  2. Jamf Threat Labs – analiza nadużyć VS Code i łańcucha infekcji (20 stycznia 2026). (jamf.com)
  3. Microsoft (VS Code Docs) – dokumentacja tasks.json, runOptions i runOn: folderOpen. (code.visualstudio.com)
  4. Security Alliance (Radar) – raport techniczny: „VS Code Tasks Abuse by Contagious Interview (DPRK)” (13 stycznia 2026). (Radar | Security Alliance)
  5. Unit 42 (Palo Alto Networks) – tło kampanii Contagious Interview oraz BeaverTail/InvisibleFerret (9 października 2024). (Unit 42)

PDFSider: nowy backdoor na Windows wykorzystywany w atakach na firmę z Fortune 100 (sektor finansowy)

Wprowadzenie do problemu / definicja luki

PDFSider (spotykane też jako PDFSIDER) to nowo opisany malware na Windows, zaprojektowany jako stealthowy backdoor do długotrwałego utrzymania dostępu i zdalnego wykonywania poleceń. Wyróżnia się tym, że jest dostarczany w sposób ułatwiający ominięcie AV/EDR: przez DLL side-loading z użyciem legalnie podpisanego programu, a do tego komunikuje się z C2 kanałem szyfrowanym i ogranicza artefakty na dysku (działając głównie „in-memory”).

W skrócie

  • Kampania została powiązana z próbą ataku na firmę z listy Fortune 100 z sektora finansowego.
  • Napastnicy łączyli socjotechnikę (podszywanie się pod wsparcie techniczne) z próbą nakłonienia pracowników do uruchomienia Microsoft Quick Assist (zdalna pomoc).
  • Łańcuch infekcji obejmował spear-phishing i archiwum ZIP z legalnym narzędziem PDF24 Creator oraz złośliwą biblioteką cryptbase.dll, która uruchamia się poprzez DLL side-loading.
  • PDFSider był obserwowany w kontekście ataków powiązanych z ransomware (m.in. wskazania dot. Qilin) i ma być używany przez więcej niż jednego operatora.
  • Komunikacja i/lub eksfiltracja ma wykorzystywać DNS (port 53), a C2 jest szyfrowane (Botan + AES-256-GCM).

Kontekst / historia / powiązania

W tym przypadku istotne są dwa elementy, które coraz częściej pojawiają się w realnych incydentach:

  1. „Remote help” jako wektor nadużyć – atakujący nie zawsze muszą zaczynać od exploita. Socjotechnika + legalne narzędzia (np. Quick Assist) pozwalają szybko przejść do interaktywnego dostępu, szczególnie gdy procesy wsparcia zdalnego są luźne.
  2. Backdoory „APT-grade” w rękach grup ransomware – Resecurity opisuje PDFSider jako narzędzie o cechach kojarzonych z APT (stealth, anti-analysis, szyfrowana łączność), ale obserwacje wskazują na wykorzystanie także w operacjach typowo „finansowych”.

Analiza techniczna / szczegóły luki

1 Dostarczenie i uruchomienie (ZIP + PDF24 + cryptbase.dll)

Zgodnie z opisami analityków, ofiara otrzymuje wiadomość spear-phishing z ZIP-em. W archiwum znajduje się:

  • legalny, podpisany cyfrowo plik wykonywalny (PDF24 Creator / „PDF24 App”),
  • oraz podstawiona biblioteka cryptbase.dll.

Mechanizm DLL side-loading polega na tym, że legalna aplikacja ładuje bibliotekę DLL z lokalizacji kontrolowanej przez atakującego (np. z tego samego katalogu), zamiast systemowej. W efekcie złośliwy DLL uruchamia się „pod przykrywką” legalnego procesu.

2 Działanie „in-memory” i zdalna powłoka

Resecurity opisuje, że PDFSider działa głównie w pamięci, minimalizując ślady na dysku, a polecenia realizuje przez niewidoczne uruchomienia cmd.exe /C ... z użyciem potoków anonimowych (m.in. z flagą CREATE_NO_WINDOW).

3 C2 / eksfiltracja: DNS + szyfrowanie Botan (AES-256-GCM)

Wymiana z C2 ma być zabezpieczona kryptograficznie przy użyciu biblioteki Botan 3.0.0 i AES-256-GCM (AEAD), a dane mają być odszyfrowywane w pamięci, co ogranicza artefakty.
Dodatkowo w opisie pojawia się eksfiltracja/łączność przez DNS (port 53) do infrastruktury VPS atakujących.

4 Anti-VM / anti-analysis

PDFSider ma wieloetapowe sprawdzanie środowiska: m.in. ocenę ilości RAM (GlobalMemoryStatusEx) w celu wykrywania sandboxów/VM oraz kontrolę obecności debuggera.

5 Przynęty (decoy)

W kampanii wykorzystywano też dokumenty-wabiki dopasowane do celu; w jednym z przykładów wskazano podszycie pod chińską instytucję rządową jako „autora” dokumentu.

Praktyczne konsekwencje / ryzyko

Dla organizacji (szczególnie z sektorów regulowanych jak finanse) PDFSider oznacza realne ryzyko w kilku wymiarach:

  • cichy, długotrwały dostęp (backdoor) zamiast jednorazowego incydentu,
  • trudniejszą detekcję (legalny proces + side-loading + szyfrowanie + in-memory),
  • most do dalszych etapów ataku, w tym kradzieży danych i finalnie wdrożenia ransomware (wskazania o użyciu przez operatorów ransomware).

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „na teraz”, możliwa do wdrożenia bez czekania na nowe łatki:

Kontrole prewencyjne (IT/Security Engineering)

  • Ogranicz/wyłącz Quick Assist, jeśli nie jest wymagany biznesowo; w innym przypadku wymuś proces autoryzacji sesji (helpdesk), MFA i ścisłą kontrolę uprawnień. (Atak opisywany bazował na próbie nakłonienia pracowników do instalacji/uruchomienia Quick Assist).
  • Zrewiduj obecność PDF24 Creator w środowisku; jeśli jest zbędny — usuń. Jeśli wymagany — ogranicz uruchamianie (allowlisting) i monitoruj nietypowe DLL w katalogach aplikacji.
  • Wdróż polityki ograniczające ładowanie niepodpisanych/nieoczekiwanych DLL w kontekstach wysokiego ryzyka (ASR/WDAC/AppLocker — zależnie od dojrzałości).

Detekcja (SOC)

  • Reguły wykrywające cryptbase.dll ładowane spoza katalogów systemowych w procesach typu PDF24/PDF24.exe (anomalia ścieżki DLL).
  • Polowania na zachowania: niewidoczne uruchomienia cmd.exe /C ..., potoki anonimowe i „dziwne” procesy-rodzice (aplikacja PDF uruchamiająca shell).
  • Monitorowanie DNS egress: nietypowe wolumeny zapytań, długie subdomeny, beaconing oraz komunikacja na port 53 do nieznanej infrastruktury VPS.

IR/Threat Intel (krótkoterminowo)

  • Wykorzystaj udostępnione przez badaczy IOC (np. wskazane nazwy/hashe i infrastruktura C2) do przeszukania telemetryki i blokad na poziomie sieci. Resecurity publikuje m.in. listę plików i C2 IP.
  • Jeśli wykryjesz side-loading w środowisku, traktuj to jako podejrzenie kompromitacji i eskaluj do pełnego triage (pamięć, EDR timeline, DNS logs, artefakty persistence).

Różnice / porównania z innymi przypadkami

PDFSider wpisuje się w szerszy trend: DLL side-loading wraca, bo jest relatywnie „tani” dla napastników, a jednocześnie skuteczny w obchodzeniu części kontroli — szczególnie gdy legalny komponent jest podpisany i powszechnie spotykany w firmach. SecurityWeek zwraca uwagę, że technika ta jest atrakcyjna zarówno dla APT, jak i cyberprzestępców, a raporty z rynku w ostatnim czasie ponownie ją podkreślają.

Podsumowanie / kluczowe wnioski

  • PDFSider to nowy backdoor na Windows opisany w styczniu 2026 r., łączący stealth, szyfrowaną łączność i wykonanie poleceń z pamięci.
  • Infekcja opiera się na ZIP + PDF24 Creator + złośliwy cryptbase.dll (DLL side-loading), a całość była widziana w ataku na organizację z Fortune 100 i w kontekście operacji ransomware.
  • Największą wartość obronną „tu i teraz” dają: kontrola narzędzi zdalnej pomocy, polityki DLL/allowlisting, monitoring DNS egress oraz reguły na nietypowe ładowania cryptbase.dll.

Źródła / bibliografia

  1. Resecurity – analiza techniczna PDFSIDER (DLL side-loading, Botan/AES-256-GCM, anti-VM, IOC) (Resecurity)
  2. BleepingComputer – kontekst ataku na Fortune 100, Quick Assist, PDF24 + cryptbase.dll, DNS exfil (BleepingComputer)
  3. SecurityWeek – podsumowanie i kontekst użycia przez grupy ransomware, technika DLL side-loading (SecurityWeek)
  4. SC Media – streszczenie incydentu, Qilin i użycie przez wielu aktorów, opis łańcucha dostarczenia (SC Media)
  5. IBM X-Force Exchange (OSINT entry) – rejestr/deskrypcja zagrożenia PDFSIDER (exchange.xforce.ibmcloud.com)

Evelyn Stealer: jak złośliwe rozszerzenia VS Code przeradzają się w pełny atak na środowisko deweloperskie

Wprowadzenie do problemu / definicja luki

Evelyn Stealer to kampania malware typu information stealer, która uderza w szczególnie wrażliwy punkt nowoczesnych firm: środowisko pracy programistów. Zamiast atakować klasyczne stacje użytkowników końcowych, operatorzy kampanii wykorzystują zaufanie do narzędzi developerskich — w tym przypadku ekosystem rozszerzeń Microsoft Visual Studio Code — aby dostarczyć wieloetapowy ładunek kradnący dane.

Z perspektywy bezpieczeństwa to nie jest „kolejny stealer”. To przykład ataku, w którym pojedyncza kompromitacja laptopa developera może stać się przyczółkiem do dalszego dostępu: tokenów chmurowych, sekretów w repozytoriach, danych produkcyjnych i — coraz częściej — zasobów kryptowalutowych.

W skrócie

  • Wejście: złośliwe rozszerzenia VS Code podszywające się pod użyteczne dodatki (m.in. warianty: BigBlack.bitcoin-black, BigBlack.codo-ai, BigBlack.mrbigblacktheme).
  • Etap 1: zrzut i uruchomienie Lightshot.dll (udającej komponent narzędzia) oraz ukryty PowerShell pobierający kolejny etap (runtime.exe).
  • Etap 2: process hollowing — wstrzyknięcie finalnego stealera do legalnego procesu Windows grpconv.exe.
  • Kradzione dane: m.in. cookies i hasła przeglądarek, dane systemowe, schowek, Wi-Fi, portfele crypto, zrzuty ekranu.
  • Eksfiltracja: przesyłanie archiwum ZIP do C2 po FTP (np. server09.mentality[.]cloud).
  • Malware ma rozbudowane anti-analysis / anti-VM, by utrudniać sandboxing i pracę analitykom.

Kontekst / historia / powiązania

Trend Micro opisuje Evelyn jako przykład „operacjonalizacji” ataków na społeczność deweloperską: narzędzie pracy (IDE + dodatki) staje się mechanizmem dostarczania malware.

Co ważne: Microsoft od dawna deklaruje wielowarstwowe zabezpieczenia Marketplace (skanowanie antywirusowe, analiza zachowania w sandboxie, weryfikacja wydawców, blocklista i wymuszone odinstalowanie złośliwych rozszerzeń). To jednak nie eliminuje ryzyka „tu i teraz” — zanim rozszerzenie zostanie wykryte i usunięte, okno czasowe wystarcza na infekcję i kradzież sekretów.

W tle mamy też szerszy trend: złośliwe kampanie w VSCode Marketplace regularnie wracają w nowych wariantach (np. ukrywanie trojana w zależnościach i plikach podszywających się pod obrazy).

Analiza techniczna / szczegóły luki

1) Initial access: złośliwe rozszerzenie VS Code

Według opisu kampanii, ofiara instaluje złośliwe rozszerzenie, które dostarcza element udający legalny komponent „Lightshot” (DLL). W relacji Trend Micro ten „downloader” podszywa się pod Lightshot.dll, a jego uruchomienie następuje w procesie legalnego Lightshot.exe (uruchomienie ma sensowny „trigger” — załadowanie DLL).

2) Etap 1: downloader (Lightshot.dll) + PowerShell

Po załadowaniu DLL malware uruchamia ukryte polecenie PowerShell, które pobiera i uruchamia kolejny etap, zapisując go w katalogu tymczasowym jako runtime.exe. Dodatkowo stosuje mechanizmy „single instance” (mutex), by nie uruchamiać się wielokrotnie.

3) Etap 2: injector i process hollowing do grpconv.exe

Drugi etap działa jako injector: odszyfrowuje payload (AES-256-CBC) i wstrzykuje go do legalnego procesu Windows grpconv.exe uruchomionego w stanie zawieszonym (CREATE_SUSPENDED), po czym wznawia wykonanie — klasyczny wzorzec process hollowing dla redukcji artefaktów i utrudnienia detekcji.

4) Final payload: Evelyn Stealer (anti-analysis + kradzież danych)

Trend Micro podkreśla warstwy unikania analizy: wykrywanie VM (m.in. po GPU/driverach), analiza hostname, dysku (np. progi pojemności), procesów narzędzi VM oraz kluczy rejestru typowych dla środowisk wirtualnych i sandboxów.

Po „weryfikacji środowiska” stealer:

  • tworzy strukturę roboczą w AppData,
  • odzyskuje dane przeglądarkowe, kończy procesy przeglądarek,
  • pobiera/odtwarza krytyczny komponent do ekstrakcji danych przeglądarkowych (abe_decrypt.dll),
  • pakuje dane i eksfiltruje je do C2 po FTP.

Praktyczne konsekwencje / ryzyko

W kampaniach celujących w developerów ryzyko jest zwykle większe niż „wyciek haseł”:

  • Kompromitacja łańcucha CI/CD: jeśli na stacji są tokeny do repozytoriów, registry (npm/pypi), pipeline’ów czy chmury, atakujący może wykonać ruch w kierunku supply chain (podmiana paczek, backdoory w buildach).
  • Dostęp do środowisk produkcyjnych: Trend Micro wprost wskazuje, że celem są organizacje mające dostęp do systemów produkcyjnych, zasobów chmurowych lub aktywów cyfrowych.
  • Kradzież kryptowalut / tożsamości: stealer obejmuje portfele crypto, cookies i dane sesyjne — to skraca drogę do przejęcia kont bez łamania MFA (np. przez hijack sesji).
  • Trudniejsza detekcja: process hollowing do legalnego procesu + anti-VM zwiększają szanse, że infekcja „przeżyje” pierwsze godziny incydentu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „na już”, ułożony praktycznie (DevSecOps/SOC/IT):

1) Zabezpiecz ekosystem rozszerzeń VS Code

  • Wdróż allowlistę dozwolonych rozszerzeń (polityki organizacyjne) i blokuj instalacje ad-hoc tam, gdzie to możliwe. Microsoft wprost opisuje możliwość egzekwowania dozwolonych rozszerzeń w organizacji.
  • Preferuj rozszerzenia od zweryfikowanych wydawców (sygnał zaufania), ale traktuj to jako heurystykę, nie gwarancję.
  • Rozważ proces wewnętrznego „review” rozszerzeń (SCA na paczce rozszerzenia, analiza połączeń sieciowych, uprawnień i telemetrii).

2) Polowanie/detekcja w endpointach (EDR/XDR)

Szukaj telemetrii typowej dla łańcucha:

  • powershell.exe uruchamiany w sposób ukryty po akcji w VS Code / po instalacji rozszerzenia,
  • nowe binaria typu runtime.exe w katalogach TEMP,
  • nietypowe uruchomienia grpconv.exe i anomalie procesu (np. „hollowing” widoczny w EDR),
  • obecność podejrzanych DLL jak Lightshot.dll w nietypowych ścieżkach związanych z rozszerzeniami.

3) Kontrola egress i protokołów „legacy”

  • Zablokuj / monitoruj FTP egress tam, gdzie nie jest absolutnie konieczny (w wielu firmach to szybkie zwycięstwo). Kampania używa FTP do C2 i eksfiltracji ZIP.
  • Dodaj alertowanie na domeny/hosty anormalne dla stacji developerskich (w przykładach pojawia się server09.mentality[.]cloud).

4) Higiena sekretów i ograniczanie blast radius

  • Wymuś krótkie TTL dla tokenów, rotację i ograniczenie uprawnień (least privilege) dla: repo, CI, chmury, rejestrów paczek.
  • Egzekwuj przechowywanie sekretów w vaultach (a nie w plikach konfiguracyjnych, schowku, zmiennych środowiskowych bez kontroli).
  • Włącz skanowanie sekretów w kodzie i na endpointach (w tym pre-commit / pre-push).

5) Reakcja na incydent

Jeśli podejrzewasz infekcję:

  • izoluj host, zrób triage artefaktów (VS Code extensions folder, TEMP, AppData),
  • rotuj wszystkie potencjalnie wykradzione sekrety,
  • przeglądnij logi dostępu do repozytoriów i chmury pod kątem nietypowych akcji z czasu infekcji.

Różnice / porównania z innymi przypadkami

Evelyn Stealer wpisuje się w serię incydentów, gdzie Marketplace rozszerzeń jest traktowany jak kanał dystrybucji malware:

  • W grudniu 2025 opisywano kampanię z 19 złośliwymi rozszerzeniami, w których payload ukryto w zależnościach i plikach podszywających się pod obrazy (np. „fake PNG”), a kod wykonywał się przy starcie IDE.
  • Microsoft jednocześnie rozwija mechanizmy obronne (skanowanie, sandbox, blocklista, automatyczne odinstalowanie) i podkreśla rolę zgłoszeń społeczności. Dla obrońców oznacza to jedno: nie można zakładać, że „Marketplace = bezpieczne”, a kontrola organizacyjna (allowlista + monitoring) pozostaje kluczowa.

Na tle innych kampanii wyróżnia się tu dojrzałość łańcucha: DLL-loader → PowerShell → process hollowing → anti-analysis → FTP exfil — czyli konstrukcja typowa raczej dla bardziej „profesjonalnych” operacji niż masowego malware z reklam.

Podsumowanie / kluczowe wnioski

  • Deweloperzy są celem wysokiej wartości, bo ich stacje to magazyn tokenów, dostępów i artefaktów łańcucha dostaw.
  • W kampanii Evelyn kluczowy jest wektor VS Code extension, a potem klasyczne techniki stealth (process hollowing do grpconv.exe) i bogata kradzież danych.
  • Największy efekt obronny dają: allowlista rozszerzeń, monitoring PowerShell/grpconv.exe, oraz ograniczenie egress (zwłaszcza FTP).

Źródła / bibliografia

  1. Trend Micro — From Extension to Infection: An In-Depth Analysis of the Evelyn Stealer Campaign Targeting Software Developers (19 stycznia 2026). (trendmicro.com)
  2. The Hacker News — Evelyn Stealer Malware Abuses VS Code Extensions to Steal Developer Credentials and Crypto (20 stycznia 2026). (The Hacker News)
  3. Microsoft (VS Code Docs) — Extension runtime security (opis mechanizmów ochronnych Marketplace). (Visual Studio Code)
  4. Microsoft for Developers — Security and Trust in Visual Studio Marketplace (11 czerwca 2025). (Microsoft Developer)
  5. BleepingComputer — Malicious VSCode Marketplace extensions hid trojan in fake PNG file (11 grudnia 2025). (BleepingComputer)

SolyxImmortal: nowy infostealer w Pythonie, który wykorzystuje Discord webhooks do cichej kradzieży danych (styczeń 2026)

Wprowadzenie do problemu / definicja luki

SolyxImmortal to świeżo opisany malware typu information stealer (infostealer) dla Windows, napisany w Pythonie, który łączy kradzież danych (m.in. haseł z przeglądarek), monitoring aktywności użytkownika, keylogging i zrzuty ekranu w jednym “monolitycznym” implantcie. Jego wyróżnikiem jest to, że do eksfiltracji używa Discord webhooks – legalnej funkcji popularnej platformy – przez co ruch bywa mniej podejrzany na poziomie sieci.

To nie jest “luka” w sensie CVE, tylko trend operacyjny: atakujący coraz częściej ograniczają własną infrastrukturę C2 i przenoszą komunikację na zaufane usługi, licząc na to, że organizacje nie chcą lub nie mogą łatwo blokować takich domen.

W skrócie

  • Cel: ciągłe, długotrwałe zbieranie danych z pojedynczej stacji roboczej (bez samorozprzestrzeniania).
  • Dane: hasła z przeglądarek Chromium, dokumenty z katalogu użytkownika, keystrokes, zrzuty ekranu.
  • Eksfiltracja: dwa hardcoded Discord webhooks – osobno na “dane strukturalne” i osobno na screenshoty.
  • Persistence: kopia w AppData, a następnie uruchamianie przez klucz Run w rejestrze użytkownika.
  • Kryptografia przeglądarek: wyciąganie klucza z pliku Local State i odszyfrowywanie danych w kontekście bieżącego użytkownika (DPAPI).

Kontekst / historia / powiązania

Z informacji badaczy wynika, że SolyxImmortal był widoczny “na wolności” w styczniu 2026 i był oferowany w podziemnym kanale na Telegramie, co wpisuje się w model commodity malware-as-a-service: narzędzie tworzy jedna osoba/grupa, a dystrybuować i używać może wiele podmiotów o różnym poziomie umiejętności.

W warstwie taktycznej to przykład “living off trusted services”: zamiast utrzymywać własne serwery C2, atakujący wykorzystują gotowe platformy (tu: Discord) i ich reputację oraz HTTPS, by utrudnić wykrycie na poziomie sieci.

Analiza techniczna / szczegóły luki

1) Architektura: monolit + wątki

SolyxImmortal jest opisany jako monolityczna aplikacja w Pythonie z centralnym kontrolerem uruchamiającym równolegle wiele wątków: zbieranie danych, keylogging, monitoring okien, zrzuty ekranu i eksfiltracja. Cała logika oraz parametry C2 są osadzone na stałe w kodzie (hardcoded), bez potrzeby dodatkowej konfiguracji.

2) Persistence: AppData + Run key

Mechanizm utrzymania się na hoście ma być prosty, ale skuteczny:

  • samokopiowanie do katalogu w ścieżce AppData użytkownika,
  • zmiana nazwy na “udającą” komponent systemowy i ustawienie atrybutów ukrycia,
  • rejestracja w kluczu Run (uruchomienie przy logowaniu użytkownika, zwykle bez uprawnień admina).

Wniosek obronny: to zostawia dość klasyczne ślady w rejestrze i w systemie plików (nietypowy binarny/EXE w AppData + autorun w HKCU).

3) Kradzież haseł z Chromium: Local State + DPAPI

Mechanika jest typowa dla wielu stealerów na Windows:

  • malware lokalizuje profile przeglądarek Chromium (Chrome/Edge/Brave i podobne),
  • odczytuje plik Local State w celu pozyskania “master key”,
  • następnie odszyfrowuje wpisy logowania z baz SQLite (w raporcie wskazano AES-GCM po stronie przeglądarki, a “wiązanie” klucza z kontem użytkownika przez DPAPI).

DPAPI (np. CryptUnprotectData) jest standardowym mechanizmem Windows do ochrony danych w kontekście użytkownika – i dlatego atakujący, uruchomieni jako użytkownik, mogą próbować go nadużyć do odszyfrowania danych zapisanych przez aplikacje.

4) Dokumenty, staging i sprzątanie

SolyxImmortal ma przeszukiwać katalog domowy użytkownika, filtrować pliki po rozszerzeniach i rozmiarze, a następnie:

  • staging w katalogu tymczasowym,
  • kompresję,
  • wysyłkę,
  • kasowanie artefaktów tymczasowych po udanej eksfiltracji.

To “sprzątanie” ogranicza materiał dla klasycznej triage (tymczasowe katalogi szybko znikają), ale nadal można szukać śladów w logach, EDR i telemetryce plików/rejestru.

5) Keylogger i screen monitoring

W raporcie wskazano:

  • keylogging z buforowaniem w pamięci i okresową wysyłką (mniej “głośny” ruch sieciowy),
  • monitoring aktywnego okna (porównywanie tytułów okien do listy słów-kluczy związanych z logowaniem/finansami) oraz robienie screenshotów po wykryciu dopasowania i także cyklicznie. (

Mapowanie do MITRE ATT&CK jest tu dość proste:

  • keylogging → T1056.001 (Input Capture: Keylogging)
  • zrzuty ekranu → T1113 (Screen Capture)

6) Eksfiltracja przez Discord webhooks

Najciekawszy element operacyjny: dwa webhooki Discorda zaszyte w kodzie – jeden do danych (np. archiwa, logi, hasła), drugi dedykowany screenshotom, a do tego hardcoded Discord user ID do “mention” operatora przy zdarzeniach wysokiej wartości.

Webhooki to legalny, powszechny mechanizm publikowania wiadomości do kanału (HTTP endpoint). W praktyce oznacza to, że malware może wysyłać dane do Discorda bez utrzymywania własnego serwera.

Praktyczne konsekwencje / ryzyko

  1. Przejęcie kont: kradzież haseł z przeglądarek + keylogging znacząco zwiększają szansę na zdobycie dostępów do VPN, SSO, bankowości, poczty i narzędzi deweloperskich.
  2. Utrata poufnych dokumentów: automatyczne “przeczesywanie” katalogu użytkownika typowo trafia w umowy, oferty, eksporty danych, pliki księgowe.
  3. Ryzyko wtórnych ataków: infostealer często bywa etapem 0 przed BEC, ransomware lub przejęciem repozytoriów kodu. (To wniosek ogólny – warto go uwzględnić w planowaniu IR).
  4. Trudniejsze wykrycie na sieci: jeśli organizacja dopuszcza ruch do Discorda, webhooki mogą “zniknąć w tłumie” HTTPS.

Rekomendacje operacyjne / co zrobić teraz

Kontrole sieciowe i proxy

  • Ogranicz/monitoruj ruch do Discorda na stacjach roboczych (zwłaszcza segmenty back-office, finanse, HR). Jeśli Discord jest biznesowo potrzebny – rozważ allowlistę tylko dla aplikacji/procesów, które mają prawo z niego korzystać. (Nie zawsze możliwe, ale warto spróbować w ZTNA/SSE).
  • Wykrywaj nietypowe POST-y do endpointów webhooków Discorda i anomalie wolumenu (małe, częste żądania z hostów, które wcześniej nie komunikowały się z Discord).

Telemetria endpoint i EDR

  • Poluj na persistence:
    • wpisy w HKCU\Software\Microsoft\Windows\CurrentVersion\Run wskazujące na binaria w AppData,
    • pliki wykonywalne w AppData o nazwach imitujących systemowe komponenty.
  • Poluj na objawy kradzieży z Chromium:
    • dostęp procesu do pliku Local State i baz SQLite profilu przeglądarki (Login Data itp.),
    • w tym samym czasie aktywność DPAPI (CryptUnprotectData) jako sygnał korelacyjny.
  • Poluj na surveillance:
    • procesy robiące screenshoty (API/artefakty plikowe) + jednoczesne połączenia wychodzące,
    • sygnały keyloggowania. (MITRE T1056.001 i T1113 mogą posłużyć jako “checklista” źródeł danych i detekcji).

Higiena tożsamości

  • Wymuś MFA/Passkeys tam, gdzie to możliwe (infostealer + keylogger to zabójcze combo dla samych haseł).
  • Rotuj hasła i unieważniaj sesje dla kont, które mogły być logowane na zainfekowanej maszynie (szczególnie: poczta, SSO, Git, narzędzia finansowe).

Incident response (IR) – praktyczny playbook

  • Jeśli podejrzewasz SolyxImmortal na hoście: izolacja stacji, triage autorunów (Run key), analiza AppData, korelacja z ruchem do Discord.
  • Przyjmij, że wyciek obejmuje hasła i dane wpisywane (keylogger), więc sama zmiana haseł “w ciemno” na tej samej stacji nie pomaga – reset realizuj z czystego urządzenia.

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

Na tle klasycznych stealerów SolyxImmortal nie wyróżnia się “nową kryptografią” czy exploitami – jego przewaga jest bardziej operacyjna:

  • C2 jako usługa (Discord webhooks), co upraszcza życie operatorom i utrudnia blokowanie,
  • rozdzielenie kanałów eksfiltracji (dane vs screenshoty), co sugeruje myślenie o niezawodności i priorytetach,
  • nacisk na ciągły monitoring (okna, hasła, kluczowe akcje) zamiast jednorazowego “grab-and-go”.

W praktyce to kolejny dowód, że granica między “commodity stealerem” a “narzędziem do inwigilacji” się zaciera – zwłaszcza gdy dodamy screen capture i mechanizmy alertowania operatora.

Podsumowanie / kluczowe wnioski

  • SolyxImmortal to Pythonowy infostealer na Windows, który łączy kradzież danych, keylogging i zrzuty ekranu w jednym implantcie.
  • Do eksfiltracji używa Discord webhooks, co zmniejsza potrzebę własnej infrastruktury i może utrudniać detekcję sieciową.
  • Persistence przez AppData + Run key jest prosta do polowania w EDR, ale skuteczna w środowiskach z luźną higieną endpointów.
  • Obrona powinna łączyć: kontrolę ruchu do Discord, detekcje na endpointach (autorun + dostęp do Local State/SQLite + DPAPI), oraz twardą higienę tożsamości (MFA/Passkeys).

Źródła / bibliografia

  1. SecurityWeek – opis zagrożenia i podsumowanie ustaleń badaczy (19 stycznia 2026). (SecurityWeek)
  2. CYFIRMA Research – “SOLYXIMMORTAL: Python Malware Analysis” (publ. 16 stycznia 2026). (CYFIRMA)
  3. Discord Developer Documentation – Webhook Resource (opis działania webhooków). (Discord)
  4. Microsoft Learn – CryptUnprotectData (DPAPI, kontekst użytkownika/komputera). (Microsoft Learn)
  5. MITRE ATT&CK – T1056.001 (Keylogging) oraz T1113 (Screen Capture). (attack.mitre.org)