Archiwa: PowerShell - Strona 18 z 34 - Security Bez Tabu

Tag: PowerShell

eScan: przejęty serwer aktualizacji posłużył do dystrybucji złośliwego „update” (supply chain) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Incydenty typu supply chain (kompromitacja łańcucha dostaw) należą do najgroźniejszych, bo nadużywają mechanizmu, któremu organizacje ufają najbardziej: legalnych aktualizacji. W przypadku eScan (MicroWorld Technologies) potwierdzono, że nieautoryzowany plik trafił do ścieżki dystrybucji aktualizacji w obrębie jednego z regionalnych klastrów serwerów, a następnie został pobrany przez część klientów w ograniczonym oknie czasowym 20 stycznia 2026 r.

W skrócie

  • eScan potwierdził nieautoryzowany dostęp do konfiguracji regionalnego serwera aktualizacji i dystrybucję błędnego/złośliwego pliku w kanale update w dniu 20.01.2026 (wąskie okno czasowe, wybrany klaster).
  • Morphisec opisał kampanię jako wieloetapową infekcję opartą o podmieniony komponent aktualizacji (m.in. Reload.exe) oraz dalsze payloady (m.in. CONSCTLX.exe), z naciskiem na „anti-remediation” (blokowanie przyszłych aktualizacji).
  • Kluczowy problem operacyjny: na systemach dotkniętych incydentem automatyczna naprawa/aktualizacja może nie działać, bo malware celowo psuje mechanikę aktualizacji.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy eScan pojawia się w kontekście nadużyć aktualizacji. W 2024 r. opisywano operację przypisywaną aktorom powiązanym z Koreą Płn., gdzie mechanizm aktualizacji eScan miał zostać wykorzystany do dostarczania backdoorów i minerów (kampania określana m.in. jako GuptiMiner) – tam scenariusz obejmował manipulację ruchem/aktualizacją (MitM) i podmianę paczki.
Różnica w 2026 r. jest zasadnicza: tym razem mówimy o dystrybucji przez legalną infrastrukturę aktualizacji (zaufany kanał vendorowy), co zwykle zwiększa „skuteczność” kampanii i utrudnia wczesne wykrycie.

Analiza techniczna / szczegóły luki

Z perspektywy TTP (tactics/techniques/procedures) w opisie Morphisec przewijają się trzy szczególnie niebezpieczne elementy:

1) Trojanizacja komponentu aktualizacji (Stage 1)
Atak miał zacząć się od podmiany 32-bitowego komponentu związanego z aktualizacją – wskazywany jest Reload.exe – który następnie realizował persistence, wykonywanie poleceń i przygotowanie gruntu pod kolejne etapy.

2) „Anti-remediation”: blokowanie przyszłych aktualizacji i naprawy
Złośliwy kod miał modyfikować m.in. plik HOSTS oraz elementy konfiguracji/rejestru eScan tak, aby utrudnić komunikację z serwerami aktualizacji i uniemożliwić pobieranie kolejnych definicji/patche’y. To klasyczny wzorzec: utrzymać foothold i „odciąć” ofiarę od leczenia.

3) Persistence przez Scheduled Tasks + artefakty w rejestrze (Stage 2/3)
Morphisec opisuje m.in. tworzenie zadań harmonogramu podszywających się pod defragmentację (np. nazwy w stylu Windows\Defrag\…Defrag, przykładowo „CorelDefrag”) oraz podejrzane klucze w HKLM\Software\{GUID} z danymi w formie tablicy bajtów (PowerShell payload).

C2 / infrastruktura
Wskazano też przykładowe adresy C2 i zasoby pobierania kolejnych payloadów (w publikacjach zwykle podawane w formie zanonimizowanej typu hxxps://… i [.]). W praktyce SOC powinien dodać je do blokad na brzegu sieci i w DNS/Proxy, a następnie skorelować z logami. (

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji korzystających z eScan:

  • Utrata zaufania do kanału aktualizacji: nawet poprawnie zarządzany endpoint może zostać zainfekowany „legalnym” update’em.
  • Zablokowanie aktualizacji definicji AV/EDR: jeśli mechanizm aktualizacji zostanie uszkodzony, stacja robocza może pozostać w stanie „ślepoty” na nowe próbki i IOC.
  • Trwała obecność (persistence) i możliwość dalszej eskalacji: opisywane backdoory/downloader’y (np. CONSCTLX.exe) sugerują gotowość do dogrywania kolejnych modułów (kradzież danych, lateral movement, ransomware).
  • Ryzyko wtórnych kompromitacji: Morphisec rekomenduje także reset poświadczeń, jeśli zainfekowane hosty mogły uzyskać dostęp do kont/zasobów (typowy następny krok po supply chain).

Rekomendacje operacyjne / co zrobić teraz

Jeśli macie eScan w środowisku (enterprise lub consumer), sensowny playbook „tu i teraz”:

  1. Ustal ekspozycję na okno 20.01.2026
    • Przejrzyj logi aktualizacji eScan oraz ruch sieciowy z tego dnia, zwłaszcza jeśli endpointy korzystały z regionalnych serwerów/CDN.
  2. Traktuj dotknięte hosty jak potencjalnie skompromitowane
    • Izoluj z sieci systemy, na których wystąpiły symptomy: błędy aktualizacji, komunikaty o niedostępności update, zmiany w HOSTS, brak nowych definicji.
  3. Polowanie na IOC (endpoint + AD + sieć)
    • Szukaj: Reload.exe (nietypowe hashe/ścieżki), CONSCTLX.exe, zadań w Windows\Defrag\, podejrzanych kluczy HKLM\Software\{GUID} z danymi binarnymi, katalogów-znaczników (np. opisywany efirst w ProgramData).
  4. Zablokuj infrastrukturę C2
    • Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
  5. Naprawa eScan może wymagać działania manualnego
    • Morphisec podkreśla, że na zainfekowanych systemach automatyczne „doleczenie” może nie zadziałać, bo mechanizm aktualizacji został celowo uszkodzony — wymagany jest kontakt z vendorem i ręczne zastosowanie patcha/narzędzia naprawczego.
  6. Forensics i higiena poświadczeń
    • Zweryfikuj, czy doszło do uruchomienia Stage 3/backdoora; w razie potwierdzenia – pełne IR: timeline, triage pamięci, przegląd kont uprzywilejowanych, rotacja haseł/tokenów.

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

2024 (GuptiMiner) vs 2026 (kompromitacja serwera/klastra aktualizacji):

  • 2024: opisywano scenariusz, w którym atakujący podmieniają paczkę aktualizacji w trakcie dostarczania (MitM / słabe zabezpieczenia kanału).
  • 2026: według potwierdzenia eScan i analizy Morphisec, złośliwy plik był dystrybuowany przez legalną infrastrukturę aktualizacji (co zwykle bardziej przypomina klasyczne supply chain w stylu „zaufany update staje się wektorem ataku”).

Wniosek praktyczny: nawet jeśli organizacja „nie klika w linki” i ma twarde polityki, update pipeline dostawcy pozostaje krytycznym punktem ryzyka, który warto obejmować monitoringiem (np. allowlisting hash/certyfikatów + anomalia w zachowaniu procesu aktualizacji).

Podsumowanie / kluczowe wnioski

  • Incydent eScan to klasyczny atak na łańcuch dostaw, gdzie legalny kanał aktualizacji posłużył do dystrybucji malware w dniu 20 stycznia 2026 r.
  • Kluczową cechą kampanii jest blokowanie mechanizmu naprawy/aktualizacji (HOSTS + konfiguracja/rejestr eScan), co podnosi koszt i czas reakcji.
  • Najrozsądniejsze podejście: szybko ustalić ekspozycję, izolować podejrzane hosty, wykonać threat hunting po IOC, zablokować C2 i wdrożyć manualną ścieżkę remediation rekomendowaną przez vendor/partnerów badawczych.

Źródła / bibliografia

  1. BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
  2. Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
  3. SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
  4. SecurityWeek – tło historyczne: kampania 2024 wykorzystująca mechanizm aktualizacji eScan (GuptiMiner, MitM). (SecurityWeek)

Nowe ataki ClickFix nadużywają skryptów Windows App-V, by dostarczać malware (Amatera Stealer)

Wprowadzenie do problemu / definicja luki

ClickFix to nie „luka” w sensie CVE, tylko powtarzalny wzorzec socjotechniczny: ofiara jest przekonywana, by sama uruchomiła polecenie w Windows (najczęściej przez Win+R) pod pretekstem „weryfikacji” albo „naprawy problemu”. W najnowszej odsłonie atakujący dołożyli sprytny twist: zamiast odpalać PowerShell bezpośrednio, proxy’ują wykonanie przez legalny, podpisany komponent Microsoftu związany z App-V.

W skrócie

  • Kampania startuje od fałszywego CAPTCHA i instrukcji: wklej/uruchom komendę w oknie „Uruchamianie” (Win+R).
  • Komenda nadużywa SyncAppvPublishingServer.vbs (App-V) odpalonego przez wscript.exe, aby „przykryć” uruchomienie PowerShell i zmienić typowy łańcuch procesów.
  • Łańcuch ma bramki anty-sandbox: sprawdzanie zachowania użytkownika, kolejności uruchomienia i stanu schowka; w środowiskach analitycznych potrafi „wisieć” w nieskończoność.
  • Konfiguracja jest pobierana z publicznego Google Calendar (.ics) (dead-drop), a jeden z etapów ukrywa payload w PNG (steganografia) i ładuje go w pamięci.
  • Finalnie celem jest Amatera Stealer (rodzina infostealer sprzedawana jako MaaS, rozwijana i „utwardzana” pod kątem evasion).

Kontekst / historia / powiązania

Microsoft wskazuje, że ClickFix rośnie od 2024 r. i bywa łączony z phishingiem, malvertisingiem oraz kompromitacją stron — a kluczową przewagą napastnika jest wymuszenie interakcji człowieka, która potrafi ominąć część automatycznych detekcji.

W tej kampanii istotne jest „życie z ziemi” (LotL/LOLBins): MITRE opisuje nadużycie SyncAppvPublishingServer.vbs jako sub-technikę System Script Proxy Execution, gdzie legalny skrypt może proxy’ować wykonanie poleceń PowerShell zamiast bezpośredniego powershell.exe.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy łańcucha (z perspektywy IR/DFIR i detekcji):

1) Wejście: fake CAPTCHA → Win+R
Użytkownik widzi stronę „human verification” i dostaje instrukcję uruchomienia komendy. To klasyczny ClickFix, ale dalej robi się nietypowo.

2) Proxy wykonania: wscript.exe + SyncAppvPublishingServer.vbs
Zamiast explorer.exe → powershell.exe, pojawia się uruchomienie przez wscript.exe i skrypt App-V (SyncAppvPublishingServer.vbs). To zmienia „process ancestry” i może obniżać skuteczność reguł nastawionych na typowe wzorce PowerShell.

3) „Execution gates” i anty-analiza
Blackpoint opisuje bramkowanie oparte m.in. o:

  • walidację kolejności kroków i zachowania użytkownika,
  • kontrolę schowka (marker potwierdzający manualne wklejenie),
  • ciche „zawieszenie” (np. nieskończone oczekiwanie), by marnować zasoby sandboxów.

4) LotL infrastruktury: konfiguracja w Google Calendar (.ics)
Zamiast twardo kodować parametry C2/loadera, kampania pobiera je z publicznego pliku kalendarza (ICS) — prostej tekstówki, którą łatwo aktualizować bez ruszania pierwszych etapów.

5) Fileless/stage’in memory + steganografia w PNG
W kolejnych etapach payload jest odszyfrowywany/rozpakowywany w pamięci, a jedna z metod dostarczania to ukrycie zaszyfrowanego ładunku w obrazie PNG (steganografia).

6) Payload: Amatera Stealer
Amatera jest opisywana przez Proofpoint jako rebranding ACR Stealera, oferowany w modelu MaaS i rozwijany pod kątem unikania detekcji; w praktyce to „warstwa monetyzacji” wielu web-inject / ClickFix-like łańcuchów.

Praktyczne konsekwencje / ryzyko

  • Celowanie w środowiska firmowe: App-V częściej występuje w środowiskach Enterprise/Education; tam też „naturalnie” działa SyncAppvPublishingServer.vbs, więc aktywność łatwiej ukryć w szumie.
  • Kradzież danych uwierzytelniających i sesji: infostealery typowo polują na przeglądarki, hasła, tokeny, portfele krypto i dane aplikacji — co szybko przekłada się na przejęcia kont i dalszą propagację. (Charakterystyka Amatera jako aktywnie rozwijanego stealera/MaaS.)
  • Niższa skuteczność „klasycznych” reguł PowerShell: jeżeli polityki/detekcje są budowane głównie wokół powershell.exe, proxy przez wscript.exe + podpisany skrypt może wyślizgiwać się spod części alertów.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h):

  1. Edukacja i komunikat do użytkowników: „Nigdy nie wklejaj poleceń do Win+R/Terminala z przypadkowych stron (CAPTCHA, ‘fix’, ‘verify’)”. Microsoft wprost wskazuje ten element jako rdzeń ClickFix i punkt, w którym szkolenie realnie obniża ryzyko.
  2. Detekcja: wscript.exe → SyncAppvPublishingServer.vbs z osadzonym PowerShell
    • MITRE sugeruje monitorowanie uruchomień tego skryptu przez wscript.exe i anomalii w linii poleceń, gdzie skrypt służy jako proxy dla PowerShell.
  3. Ograniczenie powierzchni: blokada skryptu, jeśli App-V nie jest wymagany
    • MITRE w mitigacjach mówi wprost: jeśli podpisane skrypty proxy-execution nie są potrzebne, warto je blokować polityką kontroli aplikacji. (WDAC/AppLocker / allow-listing).

Wzmocnienia średnioterminowe (1–4 tyg.):

  • Hardening stacji: ograniczenie możliwości uruchamiania narzędzi i interpreterów skryptowych tam, gdzie nie są niezbędne (w tym kontrola VBScript/WSH w środowisku).
  • Telemetria PowerShell: gdzie to możliwe, włącz/utrzymaj logowanie (Script Block Logging/AMSI) i koreluj z nietypowym proces ancestry (PowerShell bez powershell.exe na wierzchu).
  • Polityki uprawnień: minimalizacja lokalnych adminów oraz kontrola makr/skryptów i stref (szczególnie gdy wektor wejścia to web).
  • Polowanie po IoC/TTP: nietypowe pobieranie .ics z publicznych usług, sekwencje loaderów „in-memory”, pobieranie PNG w kontekście skryptów i późniejsze deszyfrowanie/uruchomienie.

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

Klasyczny ClickFix często sprowadza się do „wklej i uruchom PowerShell”. Microsoft opisuje, że wariantów jest wiele, ale rdzeń pozostaje ten sam: użytkownik wykonuje polecenie, bo wygląda na element weryfikacji/naprawy.

To, co wyróżnia opisywaną kampanię, to proxy execution przez App-V (LOLBin) oraz wieloetapowa, konsekwentna optymalizacja pod anty-analizę: bramkowanie schowkiem i kolejnością, dead-drop w Google Calendar i steganografia w PNG, wszystko z naciskiem na „ciche” wykonanie w pamięci.

Podsumowanie / kluczowe wnioski

  • ClickFix dalej działa, bo wykorzystuje nawyk „szybkiego naprawiania” problemu — a ta kampania pokazuje, że napastnicy potrafią go połączyć z podpisanymi komponentami Windows i przemyślanym łańcuchem evasion.
  • SyncAppvPublishingServer.vbs nie jest egzotyką w ATT&CK — to rozpisana technika proxy-execution; jeśli masz App-V, musisz liczyć się z nadużyciem tego elementu.
  • Największy „ROI” na start: uświadomienie użytkowników + detekcje na wscript/App-V + kontrola aplikacji (blokuj, jeśli niepotrzebne).

Źródła / bibliografia

  1. BleepingComputer – „New ClickFix attacks abuse Windows App-V scripts to push malware” (26 stycznia 2026) (BleepingComputer)
  2. Blackpoint Cyber – „Novel Fake CAPTCHA Chain Delivering Amatera Stealer” (Blackpoint)
  3. MITRE ATT&CK – T1216.002 System Script Proxy Execution: SyncAppvPublishingServer (attack.mitre.org)
  4. Microsoft Security Blog – „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21 sierpnia 2025) (Microsoft)
  5. Proofpoint – „Amatera Stealer: Rebranded ACR Stealer With Improved Evasion, Sophistication” (16 czerwca 2025) (Proofpoint)

7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać

Dlaczego to ma znaczenie

Gdy dochodzi do cyberincydentu, czas działa na niekorzyść obrony. To, jak zespół zareaguje w pierwszych godzinach, decyduje o tym, czy incydent będzie tylko drobnym potknięciem, czy pełnowymiarową katastrofą. Dobre przygotowanie potrafi zamienić potencjalny paraliż firmy w kontrolowane zdarzenie o minimalnym wpływie. Z kolei brak planu i chaotyczne działania “na gorąco” często tylko pogarszają sytuację.

Czytaj dalej „7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać”

Wieloetapowa kampania phishingowa w Rosji: Amnesia RAT + ransomware (Hakuna Matata) i WinLocker, a wszystko bez exploitów

Wprowadzenie do problemu / definicja luki

Opisywana kampania to dobry przykład „pełnego przejęcia stacji roboczej bez podatności”: atak nie potrzebuje CVE ani exploita, bo opiera się na socjotechnice, natywnych mechanizmach Windows oraz nadużyciu zaufanych usług (GitHub/Dropbox/Telegram). Łańcuch zaczyna się od archiwum z przynętami biznesowymi (w tym skrótem LNK podszywającym się pod plik tekstowy), a kończy kombinacją: Amnesia RAT (kradzież danych i zdalna kontrola) + ransomware pochodne Hakuna Matata (szyfrowanie) + WinLocker (blokada interakcji z systemem).

Kluczowym „wyróżnikiem” jest operacyjne użycie defendnot – narzędzia PoC, które potrafi doprowadzić do samowyłączenia Microsoft Defender przez rejestrację fałszywego AV w Windows Security Center (WSC).

W skrócie

  • Cel/geografia: użytkownicy i organizacje w Rosji; przynęty osadzone w realiach biurowo-księgowych.
  • Wejście: archiwum z dokumentami-wabikami + LNK z podwójnym rozszerzeniem, uruchamiający PowerShell.
  • Infrastruktura: skrypty na GitHub, binaria na Dropbox (modułowość i odporność na blokady).
  • Ewazja/utrudnianie obrony: ukrywanie okna PowerShell, opóźnienie 444 s, mocna obfuskacja VBE, eskalacja przez wymuszanie UAC, masowe zmiany konfiguracji Defender + defendnot (WSC).
  • Efekt: kradzież danych i zdalne sterowanie (Amnesia RAT), szyfrowanie plików, podmiana adresów kryptowalut w schowku, końcowa blokada systemu (WinLocker).

Kontekst / historia / powiązania

Badanie techniczne opublikował Fortinet FortiGuard Labs (20 stycznia 2026), a temat szybko podchwyciły media branżowe (m.in. 24 stycznia 2026).

W tej samej fali doniesień pojawiają się także inne kampanie wymierzone w rosyjskie podmioty (np. Operation DupeHike / UNG0902 z implantem DUPERUNNER i frameworkiem AdaptixC2 czy aktywność Paper Werewolf/GOFFEE z XLL-ami). Warto to traktować jako szerszy krajobraz zagrożeń „office-themed lures → LNK/archiwum → loader”, a nie dowód bezpośredniego powiązania z opisywaną kampanią.

Analiza techniczna / szczegóły luki

1) Etap początkowy: archiwum + LNK „udający dokument”

Ofiara dostaje skompresowane archiwum z wieloma plikami-wabikami oraz złośliwym skrótem LNK. Nazwa LNK wykorzystuje podwójne rozszerzenie (np. „…txt.lnk”), by wyglądać jak zwykły plik tekstowy.

Po uruchomieniu LNK wykonywany jest PowerShell, który pobiera kolejny skrypt (loader) z repozytorium na GitHub.

2) Loader PowerShell: „dym i lustra” + sygnał do operatora

Pierwszy skrypt:

  • ukrywa widoczną egzekucję (np. chowa okno PowerShell),
  • generuje i otwiera dokument-wabik w profilu użytkownika,
  • wysyła potwierdzenie wykonania do operatora przez Telegram Bot API,
  • czeka 444 sekundy, po czym uruchamia kolejny etap: obfuskowany skrypt VBE.

Ten „projekt” jest typowy dla kampanii nastawionych na elastyczność: pierwszy etap jest lekki, a funkcje można wymieniać po stronie hostowanego repozytorium bez zmiany całego łańcucha.

3) Orkiestrator VBE: obfuskacja + składanie payloadu w pamięci + wymuszanie UAC

Kolejny komponent (VBE) jest mocno obfuskowany i pełni rolę kontrolera, który rekonstruuje następny etap w pamięci, ograniczając artefakty na dysku. W dalszej fazie skrypt sprawdza uprawnienia i – jeśli trzeba – potrafi natrętnie wyświetlać prompt UAC, aby skłonić użytkownika do podniesienia uprawnień.

4) Neutralizacja ochrony: Defender „rozbrojony” kilkoma metodami

Fortinet opisuje sekwencję działań obniżających widoczność i skuteczność EPP/AV, w tym:

  • dodawanie wykluczeń Defender dla typowych katalogów roboczych (ProgramData, Desktop, Downloads itd.),
  • wyłączanie dodatkowych komponentów ochrony przez PowerShell,
  • modyfikacje polityk/rejestru ograniczające narzędzia administracyjne i diagnostyczne,
  • użycie defendnot, aby zarejestrować fałszywy AV w WSC i doprowadzić do samowyłączenia Defendera „dla uniknięcia konfliktu”.

To ostatnie jest krytyczne: defendnot nie musi „zabijać” procesów Defendera wprost – wykorzystuje model zaufania Windows Security Center. Huntress podkreśla, że narzędzie opiera się na (w ich opisie) nieudokumentowanych API WSC do rejestracji sfabrykowanego produktu AV.

5) Rozpoznanie i obserwacja: zrzuty ekranu + eksfiltracja przez Telegram

Po osłabieniu ochrony następuje rozpoznanie środowiska i monitoring aktywności, m.in. moduł robiący screenshot co 30 sekund oraz eksfiltracja przez Telegram (Bot API), z możliwością użycia zewnętrznych hostingów plików dla większych paczek danych (np. GoFile).

6) Payloady końcowe: Amnesia RAT + ransomware + WinLocker

Amnesia RAT (pobierany z Dropbox) ma szerokie możliwości: kradzież danych z przeglądarek, portfeli krypto, Discord/Steam/Telegram, zbieranie metadanych systemu, zrzuty ekranu, obraz z kamery, audio z mikrofonu, schowek, tytuł aktywnego okna oraz pełna zdalna interakcja (enumeracja procesów, shell, dowolne payloady).

Równolegle/po nim uruchamiany jest ransomware wywodzący się z rodziny Hakuna Matata, który szyfruje zestawy plików (dokumenty, archiwa, multimedia, kod źródłowy, zasoby aplikacji) i ubija procesy, które mogłyby przeszkadzać. Dodatkowo monitoruje schowek i podmienia adresy portfeli kryptowalut na kontrolowane przez atakujących. Łańcuch kończy WinLocker blokujący interakcję z systemem.

7) Mitre ATT&CK

Fortinet mapuje zachowania m.in. na: T1566.001 (Phishing: Attachment), T1059.001 (PowerShell), T1059.005 (VBScript), T1562.001 (Impair Defenses), T1113 (Screen Capture), T1486 (Data Encrypted for Impact).

Praktyczne konsekwencje / ryzyko

  • Ryzyko „pełnego incydentu” na endpointach: od kradzieży danych i przejęcia sesji po szyfrowanie plików i zablokowanie stanowiska.
  • Szybka eskalacja bez CVE: klasyczne „patchuj i śpisz spokojnie” nie wystarczy, bo łańcuch opiera się o zachowania użytkownika i funkcje systemu.
  • Trudniejszy takedown i filtracja: GitHub/Dropbox są powszechne w firmach; blokada „na sztywno” bywa trudna operacyjnie, a atakujący rozdzielają komponenty po usługach.
  • Obrona punktowa może zawieść: jeśli atakujący zdoła wyłączyć/ograniczyć Defendera (wykluczenia/polityki/defendnot), endpoint staje się „ślepy” na krytycznym etapie.

Rekomendacje operacyjne / co zrobić teraz

1) Zbij łańcuch na wejściu (email/WWW/endpoint)

  • Blokuj/oznaczaj archiwa z LNK oraz pliki z podwójnymi rozszerzeniami (np. *.txt.lnk). Rozważ politykę: „LNK z poczty = kwarantanna”.
  • Monitoruj i ogranicz PowerShell: logowanie Script Block, Constrained Language Mode (tam gdzie ma sens), kontrola -ExecutionPolicy Bypass i podejrzanych wzorców typu irm … | iex.
  • Wprowadź reguły ograniczające uruchamianie skryptów z katalogów użytkownika i ProgramData (allowlisting/AppLocker/WDAC – w zależności od dojrzałości).

2) Utrudnij rozbrajanie Defendera

  • Włącz Ochronę przed naruszeniami (Tamper Protection), bo jest projektowo nastawiona na blokowanie nieautoryzowanych zmian w ustawieniach ochrony i m.in. uniemożliwia modyfikację/dodawanie wykluczeń.
  • Dodaj detekcje na:
    • nagłe masowe dodawanie wykluczeń Defender,
    • wyłączanie komponentów ochrony,
    • nietypową rejestrację produktu AV w WSC / zmiany w stanie „kto jest AV”.

3) Odetnij C2/eksfiltrację i „sygnały powodzenia”

  • Polityki sieciowe/Proxy: alerty na Telegram Bot API z segmentów użytkowników, zwłaszcza gdy to nie jest zatwierdzona usługa.
  • DLP/egress: obserwuj nietypowe uploady do zewnętrznych hostingów plików (w raporcie pojawia się m.in. GoFile jako kanał dla większych danych).

4) Wczesne wskaźniki kompromitacji (praktyczne playbooki SOC)

  • Procesy/komendy: powershell.exe startujący z kontekstu LNK/Explorer i pobierający treść z GitHub, potem VBScript/WSH.
  • Artefakty behawioralne: nagłe ograniczenie narzędzi administracyjnych, zmiany skojarzeń plików (file association hijacking), cykliczne zrzuty ekranu.
  • Zasada IR: jeżeli widzisz „Defender nagle zgasł” + dziwne wykluczenia + podejrzane skrypty, traktuj to jak incydent wysokiej wagi (przed szyfrowaniem bywa bardzo mało czasu).

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

  • Defender bypass przez WSC (defendnot) to inna klasa niż klasyczne „wyłącz AV rejestrem”. Binary Defense opisuje tę ideę jako „przekonanie Windows, by samo wyłączyło ochronę”, zamiast bezpośredniego łamania Defendera.
  • Nadużycie zaufanych usług (GitHub/Dropbox) przypomina trend widoczny także w innych wieloetapowych kampaniach: legalna infrastruktura utrudnia blokowanie i zwiększa „szum tła” w logach.
  • Warto odróżnić ten przypadek od AiTM/BEC (np. SharePoint/OneDrive do kradzieży sesji i przejęć kont) – tam celem bywa tożsamość i poczta, tu finalnie dochodzi do kompromitacji endpointu i destrukcji danych. (Jeśli chcesz, mogę przygotować zestawienie TTP „endpoint takeover” vs „identity takeover” na jednym diagramie).

Podsumowanie / kluczowe wnioski

  1. To kampania „bez-CVE”, więc priorytetem stają się: kontrola uruchamiania skryptów, ochrona przed socjotechniką oraz monitoring zmian konfiguracji bezpieczeństwa.
  2. Rozdzielenie komponentów między GitHub i Dropbox zwiększa żywotność ataku i komplikuje reakcję.
  3. defendnot pokazuje, jak narzędzia dual-use (PoC) mogą przejść do realnych łańcuchów infekcji – i czemu „tamper protection + telemetry” to dziś must-have, a nie opcja.

Źródła / bibliografia

  1. Fortinet FortiGuard Labs – „Inside a Multi-Stage Windows Malware Campaign” (Cara Lin, 20.01.2026). (Fortinet)
  2. The Hacker News – „Multi-Stage Phishing Campaign Targets Russia with Amnesia RAT and Ransomware” (24.01.2026). (The Hacker News)
  3. Huntress – „Detecting Malicious Security Product Bypass Techniques” (defendnot / WSC). (Huntress)
  4. Binary Defense – „DefendNot: Turning Windows Defender Against Itself”. (Binary Defense)
  5. Microsoft Learn (PL) – „Chroń ustawienia zabezpieczeń z ochroną przed naruszeniami (Tamper Protection)”. (Microsoft Learn)

INC Ransomware: błąd OpSec ujawnił infrastrukturę i pozwolił odzyskać dane 12 ofiar w USA

Wprowadzenie do problemu / definicja luki

W ransomware zwykle zakładamy, że po eksfiltracji dane „znikają” w ekosystemie przestępców: trafiają na serwery pośrednie, do chmury, na leak site albo do prywatnych archiwów grupy. Ten przypadek pokazuje, że czasem o losie danych decyduje nie kryptografia, a operacyjna higiena atakujących (OpSec).

W styczniu 2026 r. ujawniono, że błąd OpSec grupy INC Ransomware doprowadził do odsłonięcia długowiecznej infrastruktury przechowującej zaszyfrowane paczki danych wielu ofiar — co finalnie umożliwiło odzyskanie danych skradzionych 12 organizacjom z USA.

W skrócie

  • Punktem startowym było klasyczne IR: wykrycie aktywnego szyfrowania na produkcyjnym SQL Server i analiza próbki wariantu RainINC.
  • Śledczy znaleźli artefakty użycia legalnego narzędzia backupowego restic (m.in. skrypty PowerShell, zmienione nazwy binarek, zmienne repozytorium), mimo że w tej konkretnej intruzji eksfiltracja poszła inną ścieżką.
  • W skrypcie new.ps1 znajdowały się (po dekodowaniu Base64) twardo wpisane parametry do repozytorium restic w S3-kompatybilnym storage (endpoint/bucket/repo) oraz zmienne środowiskowe typu AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_PASSWORD.
  • Kontrolowana enumeracja repozytoriów doprowadziła do identyfikacji zaszyfrowanych danych 12 niepowiązanych ofiar (różne branże), a następnie do ich odszyfrowania i zabezpieczenia we współpracy z organami ścigania.

Kontekst / historia / powiązania

INC Ransomware działa w modelu ransomware-as-a-service (RaaS) co najmniej od 2023 r. i łączy szyfrowanie z presją publikacyjną (double extortion). W przeszłości przypisywano jej ataki na organizacje z różnych krajów i sektorów, a jej operacje często pokazują „enterprise’owy” poziom standaryzacji narzędzi i procedur.

W tym incydencie istotne jest nie „kolejne ransomware”, tylko to, jak atakujący próbowali ukryć eksfiltrację w „normalnym” ruchu operacyjnym. MITRE ATT&CK opisuje ten wzorzec jako eksfiltrację przez usługi webowe / chmurowe (np. obiekty w chmurze), co bywa trudne do odróżnienia od legalnych procesów w organizacji.

Analiza techniczna / szczegóły luki

1) Punkt wejścia w analizę: szyfrowanie i staging w „niewinnej” lokalizacji

W badanej sprawie ładunek ransomware uruchomiono z C:\PerfLogs\win.exe (PerfLogs to katalog domyślnie obecny w Windows i bywa ignorowany). Korelacja TI wskazała na wariant RainINC powiązany z INC.

2) Artefakty restic jako „ślad kampanii”, a nie pojedynczego incydentu

Kluczowy zwrot nastąpił, gdy w środowisku znaleziono pozostałości po restic, mimo że w tej konkretnej intruzji dane miały zostać skopiowane inaczej (np. podczas ruchu bocznego). To zasugerowało, że restic jest elementem powtarzalnego toolchainu INC, wdrażanym selektywnie.

Śledczy odnotowali m.in.:

  • binarkę restic podmienioną nazwą (np. winupdate.exe) i lokowaną w podejrzanych miejscach (np. System32),
  • skrypty PowerShell do uruchamiania backupu,
  • zmienne konfiguracyjne repozytorium i komendy backupu,
  • listy plików sterujące selektywną kradzieżą.

3) „Wpadka” OpSec: twardo wpisane parametry dostępu do S3-kompatybilnego repo

Najbardziej obciążającym artefaktem był new.ps1 z komendami zakodowanymi Base64. Po dekodowaniu ujawniał on schemat uruchomienia restic oraz twardo wpisane dane potrzebne do połączenia z repozytorium w obiektowej chmurze (S3-kompatybilny endpoint), w tym RESTIC_REPOSITORY i RESTIC_PASSWORD oraz klucze w stylu AWS.

To ważne z dwóch powodów:

  1. Restic szyfruje dane po stronie klienta i przechowuje je w repozytorium jako nieczytelne obiekty — więc przejęcie „gołych” blobów nic nie daje bez poprawnej konfiguracji.
  2. Skrypt pozostawił wystarczająco dużo „kontekstu”, by badacze mogli bez destrukcyjnych działań enumerować snapshoty repozytoriów (w logice restic, a nie w logice samego S3) i zidentyfikować dane wielu ofiar.

4) Efekt: repozytoria jako długowieczna „hurtownia” łupów

Hipoteza okazała się trafna: infrastruktura restic/S3 była najwyraźniej wielokrotnie używana i nie została zdemontowana po zakończeniu negocjacji z pojedynczą ofiarą. Enumeracja wykazała zaszyfrowane dane 12 niepowiązanych podmiotów (m.in. healthcare, manufacturing, tech, usługi profesjonalne).

Praktyczne konsekwencje / ryzyko

  • Dla ofiar: nawet jeśli incydent jest „zamknięty” (negocjacje, płatność lub brak płatności), dane mogą dalej zalegać w infrastrukturze atakujących — czasem dłużej, niż wszyscy zakładają.
  • Dla obrońców: legalne narzędzia (backup, synchronizacja, zdalna administracja) coraz częściej stają się bronią. Ruch wygląda jak „normalny”, a eksfiltracja do chmury wpisuje się w znane taktyki ATT&CK.
  • Dla IR/DFIR: artefakty z „nieużytego” narzędzia mogą być cenniejsze niż sama próbka ransomware — bo prowadzą do infrastruktury i metod operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

1) Threat hunting: gdzie patrzeć (konkretne tropy)

  • Telemetria procesów/EDR pod kątem uruchomień z nietypowych lokalizacji: C:\PerfLogs\ oraz „binarki systemowe” uruchamiane z katalogów stagingowych.
  • Wykrywanie restic i „podszywek” typu winupdate.exe, zwłaszcza gdy:
    • binarka pojawia się w System32 lub innych wrażliwych ścieżkach,
    • wykonywana jest z parametrami backupu --files-from (selektywna kradzież).
  • PowerShell: alerty na Base64 w poleceniach oraz skrypty ustawiające zmienne środowiskowe AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_REPOSITORY, RESTIC_PASSWORD.

2) Kontrola egress i chmury

  • Ogranicz/monitoruj ruch do S3-kompatybilnych endpointów (nie tylko „AWS proper”), zwłaszcza z serwerów, które nie powinny wykonywać backupów do Internetu.
  • Wprowadź allow-listę domen/IP dla backupów i wymuś identyfikację aplikacji (proxy/NGFW) — „backupowy” ruch z nietypowego procesu to sygnał ostrzegawczy.

3) Gotowość na ransomware: procedury i odporność

  • Uporządkuj plan reakcji (izolacja, triage, polowanie na lateral movement, analiza danych wrażliwych) według checklist i dobrych praktyk dla ransomware.
  • Zadbaj o kopie zapasowe odporne na sabotaż (immutability/offline), regularne testy odtwarzania i segmentację uprawnień do repozytoriów backupowych.

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

W wielu kampaniach ransomware spotyka się narzędzia „living off the land” (legalne, powszechne w IT), ale ten przypadek wyróżnia się tym, że:

  • restic nie był tylko „narzędziem do kradzieży”, ale też standardowym elementem infrastruktury, potencjalnie współdzielonym między kampaniami,
  • błąd OpSec polegał na pozostawieniu artefaktów umożliwiających rekonstrukcję sposobu dostępu do repozytoriów (a nie na „dziurze” w chmurze),
  • skala odzysku danych (wielu niepowiązanych poszkodowanych) jest rzadkością w realnych sprawach ransomware.

Podsumowanie / kluczowe wnioski

  • Najcenniejsze w IR bywa to, co wygląda na „szum”: skrypty, staging, pozostałości po legalnych narzędziach.
  • INC wykorzystało restic i S3-kompatybilny storage do utrzymania zaszyfrowanych łupów w sposób przypominający legalne backupy — ale ich OpSec nie dowiózł.
  • Dla obrony oznacza to jedno: jeśli polujesz na ransomware, poluj też na „backup-like exfiltration” i na wszelkie anomalie wokół narzędzi kopii zapasowych, PowerShell oraz ruchu do chmury.

Źródła / bibliografia

  1. BleepingComputer — „INC ransomware opsec fail allowed data recovery for 12 US orgs” (22 stycznia 2026). (BleepingComputer)
  2. Cyber Centaurs — „When Ransomware Makes a Mistake Inside INC Ransomware’s Backup Infrastructure” (22 stycznia 2026). (Digital Forensics & Data Breach Services)
  3. restic docs — „Preparing a new repository” (S3 i backendy S3-kompatybilne). (restic.readthedocs.io)
  4. MITRE ATT&CK — T1567 / T1567.002 (Exfiltration Over Web Service / Exfiltration to Cloud Storage). (attack.mitre.org)
  5. CISA — #StopRansomware Guide / ransomware response resources. (CISA)

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)

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)