Archiwa: APT - Strona 15 z 32 - Security Bez Tabu

OpenSSL łata lukę wysokiej wagi mogącą prowadzić do RCE (CVE-2025-15467). Co trzeba wiedzieć i zrobić

Wprowadzenie do problemu / definicja luki

Pod koniec stycznia 2026 r. projekt OpenSSL opublikował aktualizacje bezpieczeństwa usuwające łącznie 12 podatności, w tym jedną oznaczoną jako HighCVE-2025-15467 – która w określonych warunkach może prowadzić do remote code execution (RCE).

Kluczowe jest to, że nie mówimy o “zwykłym TLS do HTTPS” w oderwaniu od reszty świata, tylko o podatnej ścieżce w parsowaniu CMS/PKCS#7, w szczególności struktur CMS AuthEnvelopedData korzystających z AEAD (np. AES-GCM). Jeśli Twoje środowisko przyjmuje lub przetwarza taki format z niezaufanego źródła (bramki S/MIME, systemy PKI/CA, import certyfikatów, workflow dokumentów podpisanych/szyfrowanych), temat robi się pilny.


W skrócie

  • CVE: CVE-2025-15467 (High) – stack buffer overflow w obsłudze CMS AuthEnvelopedData przy AEAD.
  • Skutek: crash/DoS, a potencjalnie RCE (zależnie od platformy i mitigacji kompilatora/systemu).
  • Warunek wejścia: aplikacja/usługa parsuje niezaufane CMS/PKCS#7 z AEAD; overflow zachodzi przed weryfikacją integralności/tagu.
  • Wersje podatne (gałęzie 3.x):
    • 3.6.0 → przed 3.6.1
    • 3.5.0 → przed 3.5.5
    • 3.4.0 → przed 3.4.4
    • 3.3.0 → przed 3.3.6
    • 3.0.0 → przed 3.0.19
  • Nie dotyczy: OpenSSL 1.1.1 i 1.0.2 (wprost oznaczone jako niepodatne).
  • FIPS: moduły FIPS dla serii 3.x nie są dotknięte, bo implementacja CMS jest poza granicą modułu.
  • Kontekst wydania: w tym samym pakiecie łatek jest też podatność moderate (CVE-2025-11187) i 10 low.

Kontekst / historia / powiązania

Informację o wydaniu łatek opisał m.in. SecurityWeek, podkreślając, że wszystkie 12 podatności zostały odkryte przez jedną firmę (Aisle), przy użyciu autonomicznego analizatora.

Datadog Security Labs zwraca uwagę na jeszcze jeden aspekt: OpenSSL rzadko nadaje “high” podatnościom potencjalnie prowadzącym do RCE, a to wydanie jest zauważalne także z perspektywy klas wejścia danych (CMS/PKCS#12), które występują w realnych pipeline’ach bezpieczeństwa (poczta, PKI, importy/eksporty).


Analiza techniczna / szczegóły luki

Co dokładnie się psuje?

CVE-2025-15467 to przepełnienie bufora na stosie podczas parsowania parametrów ASN.1 dla AEAD w strukturach CMS AuthEnvelopedData. W praktyce problem dotyczy pola IV (Initialization Vector): zakodowana w ASN.1 długość IV jest kopiowana do bufora o stałym rozmiarze bez wystarczającej walidacji, co pozwala doprowadzić do zapisu poza buforem (out-of-bounds write).

Dlaczego “pre-auth” ma znaczenie?

Overflow występuje przed weryfikacją tagu uwierzytelniającego/integrowości, więc atakujący nie musi posiadać poprawnych kluczy ani generować poprawnej kryptograficznie wiadomości, aby “trafić” w podatną ścieżkę. To podnosi realność ataku wszędzie tam, gdzie parser może zetknąć się z danymi od strony napastnika (np. inbound e-mail, upload pliku, integracje B2B).

RCE vs DoS

OpenSSL i NVD opisują skutki jako DoS (najbardziej typowy) oraz potencjalne RCE, zależne od platformy i mitigacji (ASLR, stack canaries, CET, hardening kompilacji, układ stosu itp.). To klasyczny przypadek: błąd pamięci daje prymityw zapisu na stosie, ale droga do stabilnego RCE bywa różna w zależności od środowiska uruchomieniowego.


Praktyczne konsekwencje / ryzyko

Kto jest najbardziej narażony?

Najwyższe ryzyko mają systemy, które:

  • automatycznie przetwarzają niezaufane CMS/PKCS#7 (np. bramki S/MIME, systemy DLP/MTA z funkcjami dekryptażu/analizy, integratory EDI/archiwizacji zabezpieczonej wiadomości),
  • oferują import materiału kryptograficznego/struktur (workflow certyfikatów, PKI tooling),
  • mają bibliotekę OpenSSL 3.x jako zależność i nie mają pełnej kontroli nad formatem danych wejściowych.

Jeśli OpenSSL jest używany głównie do handshake TLS, a aplikacja nie dotyka CMS/PKCS#7 z niezaufanych źródeł, osiągalność podatnej ścieżki bywa ograniczona. Datadog wprost sugeruje takie rozróżnienie w ocenie ekspozycji.

Wpływ na dystrybucje i pakiety systemowe

Dystrybucje publikują własne biuletyny i backporty. Przykładowo Ubuntu w swoim USN opisuje CVE-2025-15467 jako błąd prowadzący do crash/DoS przy niepoprawnym parsowaniu CMS AuthEnvelopedData. To ważne, bo w praktyce “wersja OpenSSL” w systemie często oznacza “wersję pakietu distro”, a nie upstream tarball.


Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję (reachability), nie tylko wersję
  • Sprawdź, czy w Twoim środowisku istnieje komponent parsujący CMS/PKCS#7 / S/MIME AuthEnvelopedData z danych od użytkownika/Internetu (MTA, gateway, usługi importu, API upload).
  1. Zaktualizuj do wersji naprawionych
    Minimalne wersje naprawione dla gałęzi 3.x (wg OpenSSL):
  • 3.0.19, 3.3.6, 3.4.4, 3.5.5, 3.6.1
    W praktyce w środowiskach produkcyjnych często aktualizujesz pakiet systemowy (np. przez apt/yum/zypper) – wtedy kieruj się biuletynem dostawcy (np. USN w Ubuntu).
  1. Uważaj na “własny OpenSSL” w runtime’ach i kontenerach
    Niektóre środowiska mogą dostarczać własne buildy OpenSSL (np. część runtime’ów/obrazów). Datadog podkreśla, że samo podbicie pakietu systemowego nie zawsze wystarczy – czasem trzeba zaktualizować cały runtime/artefakt.
  2. Mitigacje tymczasowe (jeśli nie możesz patchować natychmiast)
  • Ogranicz/wyłącz przetwarzanie niezaufanego S/MIME/CMS AuthEnvelopedData tam, gdzie to możliwe (polityki gateway, izolacja pipeline’u, sandbox).
  • Rozważ uruchamianie parserów w izolacji (separacja procesu, seccomp/AppArmor/SELinux, ograniczenia uprawnień) – to nie naprawia błędu, ale redukuje blast radius w scenariuszu RCE. (To jest dobra praktyka ogólna przy parserach danych binarnych.)
  1. Monitoring i IR
    Na dziś opisy źródłowe skupiają się na aktualizacji i ocenie ekspozycji; nie wynika z nich jednoznacznie, że istnieje masowa eksploatacja “in the wild”. Mimo to, traktuj to jak podatność parsera: monitoruj crashe procesów (segfault), wzrost błędów w usługach mail/PKI oraz nietypowe wejścia CMS/PKCS#7.

Różnice / porównania z innymi przypadkami

  • Nie “kolejny Heartbleed”: wektor jest znacznie bardziej specyficzny – dotyczy parsowania CMS AuthEnvelopedData z AEAD, a nie każdego połączenia TLS. To dobra wiadomość dla typowych serwerów WWW, ale zła dla systemów, które masowo obrabiają S/MIME/CMS.
  • Waga “High” i potencjalne RCE: Datadog zauważa, że OpenSSL rzadko klasyfikuje potencjalne RCE aż tak wysoko, co sugeruje ostrożność w bagatelizowaniu tego jako “tylko DoS”.
  • Podobieństwo klasowe: to klasyczny błąd pamięci (CWE-787 / out-of-bounds write) – a więc kategoria, która historycznie bywa trudna w ocenie “czy to na pewno RCE”, bo dużo zależy od kompilacji i mitigacji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-15467 to High w OpenSSL 3.x: przepełnienie stosu w parsowaniu CMS AuthEnvelopedData (AEAD).
  • Realny wpływ zależy od tego, czy Twoja aplikacja parsuje niezaufane CMS/PKCS#7 – w takich środowiskach priorytet patchowania powinien być wysoki.
  • Aktualizuj do: 3.0.19 / 3.3.6 / 3.4.4 / 3.5.5 / 3.6.1 (lub odpowiednich backportów dystrybucji).
  • Jeśli nie możesz patchować natychmiast: ogranicz powierzchnię (S/MIME/CMS), izoluj parsery, wzmocnij monitoring crashy – ale traktuj to jako rozwiązania przejściowe.

Źródła / bibliografia

  1. OpenSSL Library – Vulnerabilities 3.4 (CVE-2025-15467; wersje podatne i naprawione, opis podatności). (openssl-library.org)
  2. OpenSSL Library – Vulnerabilities (opis wpływu i scenariuszy CMS/PKCS#7). (openssl-library.org)
  3. NVD – CVE-2025-15467 (opis techniczny, CWE-787, referencje). (NVD)
  4. Datadog Security Labs – analiza styczniowego wydania OpenSSL 2026 (kontekst, reachability, wskazówki oceny). (securitylabs.datadoghq.com)
  5. SecurityWeek – informacja o wydaniu i kontekście (12 podatności, CVE-2025-15467 jako High). (SecurityWeek)
  6. Ubuntu Security Notice USN-7980-1 (perspektywa dystrybucji / pakietów). (Ubuntu)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.


W skrócie

  • Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
  • W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
  • Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
  • Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.


Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

  • odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
  • uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
  • buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

  • monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
  • telemetria aktywnego okna (np. tytuł okna),
  • HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

  • plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
  • plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
  • rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.


Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
  • Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
  • Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

  1. Ochrona poświadczeń i sesji
  • Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
  • Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).
  1. Detekcja na endpointach (EDR)
  • Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
  • Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).
  1. Kontrola ruchu do usług chmurowych
  • Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
  • W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).
  1. Higiena oprogramowania i odporność na sideloading
  • Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
  • Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.


Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.


Źródła / bibliografia

  1. BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
  3. Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
  4. IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

2024 VMware vCenter: krytyczna luka CVE-2024-37079 znów na celowniku – trwa eksploatacja “in the wild”

Wprowadzenie do problemu / definicja luki

vCenter Server to centralny komponent zarządzania środowiskiem VMware vSphere, często stojący “w sercu” wirtualizacji w firmach. Jeśli atakujący przejmie vCenter, zwykle zyskuje ścieżkę do kontroli nad hostami ESXi, maszynami wirtualnymi, siecią wirtualną i mechanizmami automatyzacji.

Właśnie dlatego krytyczna podatność CVE-2024-37079 (ocena CVSS 9.8) wraca jak bumerang: według ostrzeżeń publicznych oraz aktualizacji doradztwa producenta istnieją przesłanki, że jest aktywnie wykorzystywana w atakach.


W skrócie

  • Co: CVE-2024-37079 – błąd typu out-of-bounds write / heap overflow w implementacji DCERPC w VMware vCenter Server, umożliwiający zdalne wykonanie kodu (RCE).
  • Jak: atak przez specjalnie spreparowane pakiety sieciowe, jeśli napastnik ma dostęp sieciowy do vCenter.
  • Kiedy załatano: poprawki opublikowano w czerwcu 2024; Broadcom zaktualizował advisory w styczniu 2026, dodając informację o eksploatacji “in the wild”.
  • Workaround: brak sensownych obejść – trzeba aktualizować.

Kontekst / historia / powiązania

Podatność CVE-2024-37079 została ujawniona w czerwcu 2024 wraz z innymi błędami w vCenter/Cloud Foundation. CERT-EU opisywał wówczas pakiet poprawek obejmujący dwie krytyczne luki RCE (CVE-2024-37079 i CVE-2024-37080) oraz oddzielną podatność do eskalacji uprawnień (CVE-2024-37081).

W styczniu 2026 sytuacja stała się pilniejsza:

  • Broadcom dopisał do advisory uwagę, że ma informacje sugerujące wykorzystanie CVE-2024-37079 w realnych atakach.
  • Media branżowe poinformowały, że luka znalazła się w centrum zainteresowania atakujących, a administracje (w tym federalne w USA) dostały twarde terminy na działanie.

Analiza techniczna / szczegóły luki

CVE-2024-37079 dotyczy implementacji DCE/RPC (DCERPC) w vCenter Server. W praktyce błąd wiąże się z niewłaściwą weryfikacją granic podczas przetwarzania danych z pakietów sieciowych, co prowadzi do przepełnienia sterty (heap overflow) i potencjalnie do zdalnego wykonania kodu.

Kluczowe cechy, które czynią podatność “atrakcyjną” operacyjnie:

  • zdalny wektor ataku (pakiety sieciowe),
  • brak konieczności interakcji użytkownika,
  • wysoki wpływ (C/I/A = High) przy krytycznej ocenie CVSS.

Brak obejść w produkcie oznacza, że w wielu środowiskach jedyną sensowną kontrolą ryzyka jest szybka aktualizacja (oraz twarde ograniczenie ekspozycji sieciowej vCenter).


Praktyczne konsekwencje / ryzyko

Jeśli CVE-2024-37079 zostanie skutecznie wykorzystana, organizacja musi liczyć się z typowymi skutkami przejęcia warstwy zarządzania wirtualizacją:

  • przejęcie kontroli nad środowiskiem vSphere (zmiany konfiguracji, uruchamianie złośliwych zadań, dostęp do konsol VM),
  • eskalacja ataku na hosty i maszyny wirtualne (ruch boczny, kradzież poświadczeń, wyłączanie zabezpieczeń),
  • ryzyko sabotażu/zaszyfrowania (vCenter bywa elementem “szybkiej ścieżki” do masowego wyłączania usług).

Warto też pamiętać o realiach ofensywnych: infrastruktura wirtualizacyjna jest historycznie lubiana zarówno przez grupy APT, jak i cyberprzestępców, bo daje wysoki zwrot z inwestycji (jeden punkt → wiele systemów).


Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję i wersje
    • Sprawdź, czy masz vCenter Server 7.0/8.0 oraz wdrożenia w ramach VMware Cloud Foundation – to kluczowe linie produktowe wskazywane jako dotknięte.
  2. Wdróż poprawki (priorytet P0)
    • Broadcom w macierzy odpowiedzi wskazuje wersje naprawione m.in.: vCenter 8.0 U2d, 8.0 U1e, 7.0 U3r (zależnie od gałęzi i zakresu CVE).
    • Ponieważ workaroundów brak, aktualizacja to jedyna realna ścieżka redukcji ryzyka.
  3. Odetnij vCenter od internetu i “szerokich” sieci
    • vCenter nie powinno być publicznie wystawione; ogranicz dostęp do segmentów administracyjnych, jump hostów i VPN, stosuj listy ACL i mikrosegmentację. (To zalecenie jest zgodne z praktyką branżową, a wprost podkreślane w komentarzach wokół tej kampanii).
  4. Polowanie na oznaki nadużyć
    • Skoro szczegóły kampanii nie są publiczne, podejdź “symptomatycznie”: nietypowe procesy/usługi na VCSA, nowe konta/klucze, zmiany ról, anomalie w logach vCenter, skoki ruchu do usług RPC, podejrzane zadania automatyzacji.
    • Zabezpiecz dowody (snapshoty, eksport logów), zanim wykonasz działania naprawcze w razie incydentu.
  5. Zarządzanie ryzykiem terminowym
    • W kontekście KEV/terminów egzekucyjnych (dla części podmiotów) w obiegu pojawia się data 13 lutego 2026 jako deadline na załatanie w administracji federalnej USA – potraktuj to jako czytelny sygnał pilności także dla biznesu.

Różnice / porównania z innymi przypadkami

  • CVE-2024-37079 vs CVE-2024-37080: oba błędy są krytyczne, oba dotyczą DCERPC i klasy heap overflow, z podobnym potencjałem RCE przy dostępie sieciowym.
  • CVE-2024-37081: to inna klasa problemu – lokalna eskalacja uprawnień wynikająca z błędnej konfiguracji sudo. Jest ważna, ale zwykle wymaga już jakiejś formy dostępu lokalnego do appliance.
  • Wątek “DCERPC w vCenter” jako powracający motyw: komentatorzy zwracają uwagę na wcześniejsze podatności w tej okolicy funkcjonalnej, co ułatwia atakującym priorytetyzację celu i budowę TTP wokół infrastruktury wirtualizacyjnej.

Podsumowanie / kluczowe wnioski

CVE-2024-37079 to klasyczny przykład “starej” krytycznej luki, która wraca ze zdwojoną siłą, gdy pojawiają się sygnały realnej eksploatacji. Jeśli zarządzasz VMware vCenter:

  • traktuj temat jako incydent waiting-to-happen,
  • aktualizuj natychmiast (brak workaroundów),
  • upewnij się, że vCenter jest ściśle odseparowane sieciowo,
  • uruchom hunt na oznaki kompromitacji w środowiskach, które mogły być narażone.

Źródła / bibliografia

  1. SecurityWeek – “2024 VMware Flaw Now in Attackers’ Crosshairs” (SecurityWeek)
  2. Broadcom (VMware) – VMSA-2024-0012 / aktualizacja o eksploatacji CVE-2024-37079 (Support Portal)
  3. NVD (NIST) – opis i metryki CVE-2024-37079 (nvd.nist.gov)
  4. CERT-EU – advisory 2024-060 dot. vCenter/Cloud Foundation (cert.europa.eu)
  5. The Register – kontekst KEV i presja terminowa (m.in. 13 lutego 2026) (theregister.com)

DynoWiper: nowy wiper użyty w nieudanej próbie sabotażu polskiego sektora energii (Sandworm)

Wprowadzenie do problemu / definicja luki

Pod koniec grudnia 2025 r. odnotowano skoordynowaną próbę ataku na polski sektor energetyczny, w której wykorzystano destrukcyjne złośliwe oprogramowanie typu wiper (malware do trwałego niszczenia danych). Według ustaleń ESET oraz relacji medialnych, atak był nieudany – nie ma dowodów na skuteczne zakłócenie działania infrastruktury.

W tym przypadku kluczowe jest to, że mówimy o klasie incydentów nastawionych nie na kradzież danych czy okup (ransomware), ale na szybkie unieruchomienie systemów poprzez kasowanie/niszczenie plików oraz potencjalne utrudnienie odtworzenia środowiska.


W skrócie

  • Atak miał miejsce 29–30 grudnia 2025 r. i obejmował m.in. dwie elektrociepłownie (CHP) oraz system wspierający zarządzanie energią z OZE (np. wiatr i fotowoltaika).
  • ESET przeanalizował próbkę nowego wipera, nadając mu nazwę DynoWiper (detekcja: Win32/KillFiles.NMO).
  • Atrybucja do grupy Sandworm (powiązanej z rosyjskim GRU) ma według ESET „średni” poziom pewności i opiera się na nakładaniu się TTP oraz podobieństwach do wcześniejszych aktywności destrukcyjnych.
  • Kontekst historyczny jest istotny: Sandworm ma udokumentowaną historię operacji destrukcyjnych, w tym kampanii przeciw energetyce.

Kontekst / historia / powiązania

Sandworm to jeden z najbardziej znanych „destrukcyjnych” aktorów APT, wiązany z jednostką GRU 74455 i aktywny co najmniej od 2009 r. W narracji wokół incydentu pojawia się też wymiar symboliczny: ESET zwraca uwagę, że działania zbiegły się z 10. rocznicą głośnego ataku na ukraińską energetykę (2015), który był szeroko opisywany jako przełomowy przykład cyberataku na infrastrukturę krytyczną.

Z perspektywy strategii zagrożeń ważny jest sam wybór celów: połączenie aktywów wytwórczych (CHP) oraz elementów „krwiobiegu” nowoczesnej energetyki – systemów komunikacji i zarządzania generacją rozproszoną (OZE).


Analiza techniczna / szczegóły luki

1) Co wiemy na pewno o DynoWiper

Publicznie udostępnione informacje są na razie dość oszczędne: ESET potwierdza analizę nowego wipera DynoWiper i wskazuje jego charakter destrukcyjny (data-wiping), a także nazwę detekcji Win32/KillFiles.NMO. Reuters i inne media streszczają, że malware miało niszczyć pliki i unieruchamiać systemy.

2) Jak typowo działają wipery w środowiskach IT/OT (użyteczne do obrony)

Ponieważ szczegóły implementacyjne DynoWiper nie zostały szeroko opisane w materiałach publicznych (na dzień publikacji źródeł), warto przełożyć „wiper” na obserwowalne artefakty obronne. W praktyce wipery często realizują część lub całość poniższych działań:

  • masowe usuwanie plików (czasem z użyciem list rozszerzeń/ścieżek) lub ich nadpisywanie,
  • kasowanie kopii zapasowych/Shadow Copies i punktów przywracania,
  • destabilizacja systemu (np. niszczenie konfiguracji, usług, krytycznych katalogów),
  • równoległe użycie narzędzi „living-off-the-land” (np. do dystrybucji w domenie) – szczególnie w kampaniach przypisywanych Sandworm, gdzie destrukcja bywa etapem końcowym po wcześniejszym dostępie i przygotowaniu środowiska. (To jest uogólnienie na bazie znanego profilu grupy w ATT&CK.)

3) Atrybucja: dlaczego Sandworm

ESET komunikuje atrybucję do Sandworm z „medium confidence”, wskazując na silne nakładanie się z wcześniejszymi aktywnościami wiperowymi tej grupy. Z kolei MITRE ATT&CK opisuje Sandworm jako grupę o profilu destrukcyjnym, z historią operacji obejmujących m.in. NotPetya i wcześniejsze kampanie przeciw sektorom państwowym i krytycznym.


Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyko w tym typie incydentu to krótki czas do efektu i wysoki koszt odtwarzania. Nawet jeśli atak nie powoduje natychmiastowego blackoutu, wiper:

  • może zatrzymać procesy biznesowe (OT/IT) przez konieczność odbudowy stacji, serwerów i domeny,
  • utrudniać sterowanie i bilansowanie (szczególnie, gdy celem są elementy komunikacji OZE z operatorami),
  • generować koszty operacyjne i reputacyjne – nawet przy braku fizycznych skutków.

W tym przypadku polskie władze i badacze mówią, że nie doszło do skutecznych zakłóceń, ale sam dobór celów (CHP + zarządzanie OZE) pokazuje, gdzie atakujący mógłby próbować uzyskać efekt „systemowy”.


Rekomendacje operacyjne / co zrobić teraz

Poniższe działania są praktyczne niezależnie od tego, czy DynoWiper pojawi się ponownie (i nawet przy ograniczonej widoczności jego IoC):

  1. Segmentacja IT/OT i kontrola przepływów
  • „Hard separation” krytycznych stref OT (SCADA/EMS/DMS, serwery inżynierskie) od IT; dopuszczaj tylko jawnie dozwolone protokoły i kierunki.
  • Bastionowanie dostępu z MFA i rejestrowaniem sesji.
  1. Wzmocnienie Active Directory i mechanizmów dystrybucji
  • Monitoruj nietypowe użycie GPO, PSExec/WMI/WinRM oraz narzędzi zdalnej administracji.
  • Ogranicz uprawnienia kont serwisowych; wprowadź JIT/JEA dla adminów.
  1. Backupy odporne na wipery
  • Kopie offline/immutable, testowane odtwarzanie (bare metal + AD recovery).
  • Osobne poświadczenia i oddzielona sieć do backupu.
  1. Detekcja behawioralna pod destrukcję
  • Alerty na: gwałtowny wzrost operacji delete/rename, masowe modyfikacje w krótkim oknie czasu, niszczenie kopii zapasowych.
  • Korelacja zdarzeń na hostach pełniących role „przesiadkowe” między IT i OT.
  1. Ćwiczenia IR ukierunkowane na „wiper scenario”
  • Procedury: izolacja segmentów, odcięcie dystrybucji narzędzi, priorytety przywracania (najpierw tożsamość, potem łączność, potem aplikacje).

Różnice / porównania z innymi przypadkami

  • DynoWiper vs klasyczne ransomware: tu celem nie jest monetyzacja, tylko degradacja zdolności operacyjnej. To zmienia priorytety: kluczowe są backupy i odtwarzanie, a nie negocjacje/odszyfrowywanie.
  • DynoWiper vs wcześniejsze operacje Sandworm: publicznie potwierdzony jest przede wszystkim „destrukcyjny DNA” Sandworm i jego historia kampanii o wysokim wpływie (MITRE opisuje m.in. NotPetya i ataki na energetykę). W przypadku DynoWiper na ten moment wiemy mniej o technikaliach, ale atrybucja ESET opiera się na zbieżnościach TTP z wcześniejszymi wiperami.

Podsumowanie / kluczowe wnioski

DynoWiper jest kolejnym sygnałem, że destrukcyjne operacje cybernetyczne nie są „historią z 2015 roku”, tylko realnym scenariuszem dla współczesnej energetyki – zwłaszcza w kontekście systemów hybrydowych łączących konwencjonalne źródła z OZE.

Najważniejsze na dziś:

  • traktuj wiper jako scenariusz „fast impact” (minuty–godziny),
  • inwestuj w odporność odtwarzania i segmentację,
  • buduj detekcję behawioralną pod masowe niszczenie danych,
  • ćwicz IR pod operacje destrukcyjne, nie tylko pod wycieki.

Źródła / bibliografia

  1. ESET Research – Sandworm behind cyberattack on Poland’s power grid in late 2025 (welivesecurity.com)
  2. The Hacker News – New DynoWiper Malware Used in Attempted Sandworm Attack on Polish Power Sector (The Hacker News)
  3. Reuters – raport o atrybucji i kontekście ataku (Reuters)
  4. TechCrunch – opis celu i kontekstu ataku (CHP + łączność OZE) (TechCrunch)
  5. MITRE ATT&CK – profil grupy Sandworm (G0034) (attack.mitre.org)

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)

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)