Archiwa: APT - Strona 29 z 45 - Security Bez Tabu

Tag: APT

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)

UK ostrzega przed trwającymi atakami prorosyjskich „hacktywistów”: DDoS wraca na pierwszy plan (NoName057(16), DDoSia)

Wprowadzenie do problemu / definicja „luki”

Brytyjskie instytucje bezpieczeństwa cybernetycznego ostrzegają przed utrzymującą się falą działań prorosyjskich grup „hacktywistycznych”, których głównym celem jest zakłócanie dostępności usług – przede wszystkim poprzez (D)DoS wymierzone w serwisy publiczne, samorządy oraz elementy infrastruktury krytycznej. Istota problemu nie polega na „wyrafinowanej exploatacji”, tylko na odporności operacyjnej: nawet technicznie proste ataki mogą wymusić kosztowną reakcję, doprowadzić do przestojów i obniżyć zaufanie do usług cyfrowych.

W skrócie

  • Ostrzeżenia (styczeń 2026) wskazują na ciągłe, powtarzalne ataki DDoS wymierzone m.in. w brytyjskie jednostki samorządu i organizacje świadczące kluczowe usługi.
  • W centrum uwagi pojawia się NoName057(16) oraz projekt DDoSia – model „crowdsourcingu” mocy obliczeniowej do prowadzenia ataków (z elementami motywacji/rywalizacji w społeczności).
  • W tle są też szersze zjawiska: wspólne ostrzeżenia partnerów międzynarodowych pokazują, że prorosyjscy aktorzy potrafią łączyć „szum DDoS” z oportunistycznymi wejściami w środowiska OT/ICS (np. przez źle zabezpieczone VNC).

Kontekst / historia / powiązania

NoName057(16) jest aktywne co najmniej od marca 2022 r. i regularnie uderzało w podmioty w państwach NATO oraz innych krajach europejskich postrzeganych jako wrogie „interesom geopolitycznym” Rosji. Grupa działa w dużej mierze przez kanały komunikacji społecznościowej (np. Telegram) i wykorzystywała platformy takie jak GitHub do dystrybucji narzędzi oraz TTP.

W lipcu 2025 r. aktywność NoName057(16) była zakłócana przez działania organów ścigania (m.in. przejęcia infrastruktury i zatrzymania), ale – jak pokazują ostrzeżenia z początku 2026 r. – presja operacyjna wróciła, co jest typowe dla grup „rozproszonych”, działających w modelu społecznościowym i trudnych do trwałego „wyłączenia”.

Równolegle brytyjski NCSC zwraca uwagę, że konflikty geopolityczne (wojna Rosji przeciw Ukrainie, napięcia międzynarodowe) napędzają wzrost liczby prorosyjskich grup hacktywistycznych, których działania są mniej przewidywalne, bo cele dobierają często pod kątem „tego, co akurat jest podatne”.

Analiza techniczna / szczegóły działań

1) DDoS jako „tania” broń na dostępność

Opisywane kampanie koncentrują się na wyłączaniu stron i usług – szczególnie tych, które mają znaczenie społeczne (informacja publiczna, usługi samorządowe, systemy obsługi mieszkańców). DDoS jest atrakcyjny, bo:

  • łatwo go „skalować” (botnety, wynajęte usługi, wolontariusze),
  • trudno jednoznacznie przypisać sprawstwo,
  • efekt (niedostępność) jest widoczny natychmiast i świetnie działa propagandowo.

2) DDoSia i model „crowdsourced DDoS”

Wątek kluczowy to DDoSia – platforma/ekosystem umożliwiający zwolennikom dorzucanie zasobów do ataku (w praktyce: klient/agent + koordynacja + motywatory). Taki model obniża próg wejścia, zwiększa dynamikę kampanii i ułatwia „odrastanie” po działaniach służb.

3) Kiedy „hacktywizm” dotyka OT/ICS

Wspólne opracowania partnerów międzynarodowych podkreślają, że część prorosyjskich grup (w tym wymieniane: CARR, Z-Pentest, NoName057(16), Sector16) prowadzi także oportunistyczne działania przeciw infrastrukturze krytycznej, wykorzystując m.in. źle zabezpieczone, internetowo dostępne VNC do uzyskania dostępu do HMI/urządzeń OT. To nie musi być APT-owa finezja – często wystarcza:

  • skanowanie usług (np. Nmap/OpenVAS),
  • password spraying / brute force na słabych lub domyślnych hasłach,
  • typowe porty VNC (np. 5900 i okolice),
  • manipulacje w GUI HMI (setpointy/parametry) oraz „dowody” w postaci screenów i nagrań publikowanych w social media.

W tej perspektywie DDoS jest tylko jednym z narzędzi nacisku; ryzyko rośnie, jeśli organizacja ma jednocześnie słabą higienę zdalnego dostępu do OT.

Praktyczne konsekwencje / ryzyko

  • Koszt i przestój: nawet krótkie przerwy w dostępności usług publicznych generują koszty, eskalacje i obciążenie zespołów (analiza ruchu, komunikacja kryzysowa, przywracanie usług).
  • Efekt społeczny: ataki na serwisy samorządowe i usługi „pierwszej potrzeby” wzmacniają przekaz propagandowy („państwo nie działa”), nawet gdy technicznie to „tylko DDoS”.
  • Ryzyko OT/ICS: w scenariuszach oportunistycznych wejść przez VNC konsekwencje mogą wykraczać poza IT (zakłócenia procesów, a w skrajnych przypadkach szkody fizyczne).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie podnoszą odporność na DDoS i „tanią” presję operacyjną (szczególnie w sektorze publicznym i u operatorów usług kluczowych):

  1. Zmapuj punkty krytyczne usług
  • Co jest „single point of failure” (DNS, reverse proxy, WAF, łącze, upstream)?
  • Jak wygląda odpowiedzialność: ISP vs hosting vs dostawca aplikacji?
  1. Wzmocnij warstwę upstream
  • Uzgodnij z ISP procedury scrubbingu/blackholingu.
  • Rozważ usługi anty-DDoS oraz CDN dla serwisów publicznych.
  • Dla kluczowych usług: redundancja u wielu dostawców (tam, gdzie to uzasadnione).
  1. Projektuj pod skalowanie i degradację kontrolowaną
  • Autoscaling w chmurze, zapas mocy, cache, kolejki.
  • „Graceful degradation”: co ma działać zawsze (np. komunikaty statusowe, kanały alternatywne).
  1. Playbook i ćwiczenia DDoS
  • Kto podejmuje decyzje o przełączeniach, ograniczeniach funkcji, komunikacji do obywateli/klientów?
  • Jak utrzymujesz dostęp administracyjny podczas ataku?
  • Testuj regularnie (table-top + testy techniczne).
  1. Jeśli masz OT/ICS: potraktuj VNC jako „czerwony alarm”
  • Usuń ekspozycję VNC do internetu; jeśli absolutnie konieczne – tylko przez bezpieczny bastion/VPN, allowlisty, MFA, rotacja haseł.
  • Inwentaryzuj zdalny dostęp do HMI/SCADA, monitoruj skanowania i próby logowania.
  • Zastosuj twarde polityki haseł i blokady anty-bruteforce.

Różnice / porównania z innymi przypadkami

  • DDoS vs APT: DDoS bywa „mało wyrafinowany”, ale jego celem jest widoczny efekt operacyjny (niedostępność). APT częściej dąży do długotrwałej obecności i kradzieży danych. To inne metryki sukcesu i inny model obrony.
  • Hacktywizm IT vs OT: w IT presja to głównie dostępność i reputacja; w OT dochodzi ryzyko procesowe (parametry, bezpieczeństwo operacji). Wspólne ostrzeżenia pokazują, że część aktorów próbuje „grać” na obu polach, choć często robi to oportunistycznie i bez głębokiej wiedzy domenowej.

Podsumowanie / kluczowe wnioski

  1. UK (styczeń 2026) sygnalizuje, że prorosyjskie grupy hacktywistyczne nie zniknęły – kampanie DDoS nadal uderzają w organizacje publiczne i usługi kluczowe.
  2. NoName057(16) + DDoSia to przykład skalowalnego, społecznościowego modelu nękania usług, który potrafi wrócić nawet po działaniach służb.
  3. Obrona to przede wszystkim odporność (architektura, upstream, procedury), a nie „jeden magiczny produkt”.
  4. Organizacje z komponentem OT/ICS powinny zakładać, że „hacktywizm” może przerodzić się w oportunistyczne wejścia przez zdalny dostęp (np. VNC) – i zamknąć te ścieżki priorytetowo.

Źródła / bibliografia

  1. BleepingComputer – ostrzeżenie UK o trwających atakach i NoName057(16)/DDoSia (19 stycznia 2026). (BleepingComputer)
  2. The Register – kontekst i nacisk na ryzyko dla usług publicznych i CNI (19 stycznia 2026). (theregister.com)
  3. The Record (Recorded Future News) – podsumowanie ostrzeżenia NCSC i odniesienie do grudniowych advisory partnerów (20 stycznia 2026). (The Record from Recorded Future)
  4. Joint Cybersecurity Advisory AA25-343A (PDF, m.in. CISA/FBI i partnerzy) – TTP: VNC, skanowanie, password spraying, sektory: woda/żywność/energia, grupy CARR/NoName057(16)/Sector16/Z-Pentest. (ic3.gov)
  5. NCSC Annual Review 2025 (PDF) – trend wzrostu hacktywizmu powiązanego z napięciami geopolitycznymi i większa nieprzewidywalność celowania. (NCSC)

Cisco łata krytyczny zero-day w AsyncOS (CVE-2025-20393) wykorzystywany od listopada – co to oznacza dla Secure Email Gateway

Wprowadzenie do problemu / definicja luki

Cisco opublikowało poprawki dla krytycznej podatności typu zero-day w systemie AsyncOS używanym przez Cisco Secure Email Gateway oraz Cisco Secure Email and Web Manager. Luka, oznaczona jako CVE-2025-20393 i oceniona na CVSS 10.0, umożliwia nieautoryzowane zdalne wykonanie poleceń z uprawnieniami roota w scenariuszu, w którym funkcja Spam Quarantine jest włączona i wystawiona do Internetu.

W skrócie

  • Co się dzieje? Aktywnie wykorzystywany zero-day pozwala na RCE jako root przez spreparowane żądania HTTP do komponentu Spam Quarantine.
  • Kogo dotyczy? Urządzeń/VA z AsyncOS, gdy Spam Quarantine jest włączone i osiągalne z Internetu.
  • Jakie są symptomy kampanii? W atakach obserwowano m.in. backdoor AquaShell, tunelowanie (AquaTunnel/ReverseSSH, Chisel) i czyszczenie logów (AquaPurge).
  • Co z priorytetem działań? CISA dodała CVE do KEV 17 grudnia 2025 r. z krótkim terminem wymuszenia działań (dla agencji federalnych: 24 grudnia 2025 r.).
  • Jest patch? Tak — Cisco wskazało wersje naprawione (szczegóły niżej).

Kontekst / historia / powiązania

Z doniesień wynika, że podatność była wykorzystywana co najmniej od listopada 2025 r., a Cisco Talos wiąże kampanię z chińsko-powiązanym aktorem śledzonym jako UAT-9686. W operacjach widoczny był nacisk na utrzymanie dostępu (persistencja) i ukrywanie śladów — m.in. poprzez instalację AquaShell oraz narzędzia do tunelowania i „sprzątania” logów.

Równolegle temat trafił do obiegu instytucjonalnego: kanadyjskie Cyber Centre opisało wpływ na produkty Cisco i potwierdziło, że warunkiem ryzyka jest ekspozycja Spam Quarantine do Internetu.

Analiza techniczna / szczegóły luki

Mechanizm podatności:
Według opisu w NVD, problem wynika z niewystarczającej walidacji żądań HTTP obsługiwanych przez funkcję Spam Quarantine. Atakujący może wysłać spreparowane żądanie HTTP do podatnego urządzenia i uzyskać wykonanie dowolnych poleceń w systemie operacyjnym z uprawnieniami root.

Warunki eksploatacji (kluczowe):

  • Spam Quarantine musi być skonfigurowane,
  • a jego interfejs/port musi być osiągalny z Internetu (to nie jest ustawienie domyślne, ale w praktyce bywa wystawiane „dla wygody” lub błędnie przez reguły publikacji).

Ocena ryzyka (CVSS):
CVSS v3.1 = 10.0, wektor: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — czyli zdalnie, bez uwierzytelnienia, o niskiej złożoności, z pełnym wpływem na poufność/integralność/dostępność.

Wersje z poprawką (wg informacji o patchach):

  • Dla Email Security Gateway / Secure Email Gateway: AsyncOS 15.0.5-016, 15.5.4-012, 16.0.4-016
  • Dla Email and Web Manager / Secure Email and Web Manager: AsyncOS 15.0.2-007, 15.5.4-007, 16.0.4-010

Praktyczne konsekwencje / ryzyko

Jeżeli podatne urządzenie było wystawione do Internetu, skutki mogą być poważniejsze niż „zwykłe RCE”:

  • Pełne przejęcie bramy pocztowej = możliwość manipulacji ruchem e-mail, regułami, kwarantanną, a w skrajnym przypadku podmiana komponentów i trwała persistencja. (Uprawnienia root mocno to ułatwiają.)
  • Wykorzystanie jako punkt wejścia do sieci przez tunelowanie (ReverseSSH/Chisel), co pasuje do profilu działań APT.
  • Utrudniona detekcja: w kampanii obserwowano narzędzia do czyszczenia logów (AquaPurge), co może zacierać ślady.

Rekomendacje operacyjne / co zrobić teraz

Poniżej plan działań, który da się wdrożyć „od razu” w SOC/IT:

  1. Inwentaryzacja i ekspozycja
    • Zidentyfikuj wszystkie instancje (sprzęt/VA) Secure Email Gateway oraz Secure Email and Web Manager.
    • Sprawdź, czy Spam Quarantine jest włączone i czy port/usługa jest osiągalna z Internetu.
  2. Natychmiastowe ograniczenie powierzchni ataku (jeśli dotyczy)
    • Zdejmij ekspozycję Spam Quarantine z Internetu (ACL/WAF/VPN, ograniczenie do adresów administracyjnych, segmentacja).
    • Traktuj to jako działanie „tu i teraz”, nawet jeśli patch już jest — bo musisz też ograniczyć ryzyko ponownej kompromitacji.
  3. Aktualizacja do wersji naprawionych
    • Zaktualizuj AsyncOS do wskazanych wersji naprawionych dla Twojej linii produktu.
  4. Hunting i weryfikacja kompromitacji
    • Szukaj artefaktów/nazw/nietypowych procesów i połączeń związanych z: AquaShell, AquaTunnel/ReverseSSH, Chisel, AquaPurge.
    • Sprawdź nietypowe sesje wychodzące (tunelowanie), nagłe braki w logach, anomalie w harmonogramach/zadaniach.
  5. Jeśli podejrzenie kompromitacji jest realne
    • Rozważ scenariusz „clean rebuild” urządzenia/VA (w kampanii widziano mechanizmy persistencji; samo „załatanie” nie zawsze jest równoznaczne z usunięciem dostępu atakującego).

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

Ten incydent jest klasycznym przykładem „edge security appliance jako cel APT”:

  • urządzenie stoi na styku Internet–organizacja,
  • obsługuje krytyczny strumień danych (poczta),
  • a przy RCE jako root może stać się stealthy pivotem (tunelowanie + czyszczenie logów).

W praktyce ryzyko bywa silnie skorelowane z jednym błędem architektury: wystawieniem funkcji administracyjnych lub pomocniczych (jak kwarantanna) bez twardych ograniczeń dostępu.

Podsumowanie / kluczowe wnioski

  • CVE-2025-20393 to krytyczny, aktywnie wykorzystywany zero-day w AsyncOS (Spam Quarantine), umożliwiający RCE jako root.
  • Największe ryzyko dotyczy środowisk, gdzie Spam Quarantine jest wystawione do Internetu.
  • Kampania wiązana z UAT-9686 obejmowała narzędzia persistencji i tunelowania (AquaShell/AquaTunnel/Chisel) oraz czyszczenie logów (AquaPurge), co podnosi wagę działań IR.
  • Patch jest dostępny — aktualizacja + weryfikacja kompromitacji to właściwa kolejność działań.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i narzędzi (AquaShell, AquaTunnel, Chisel, AquaPurge), kontekst KEV. (BleepingComputer)
  2. SecurityWeek – informacje o wydaniu poprawek i wersjach naprawionych. (SecurityWeek)
  3. NVD (NIST) – techniczny opis podatności, CVSS, warunki eksploatacji, metadane KEV. (nvd.nist.gov)
  4. CIS (MS-ISAC advisory) – warunki podatności, zalecenia i kontekst operacyjny. (CIS)
  5. Canadian Centre for Cyber Security – potwierdzenie zakresu wpływu i odniesienia do KEV. (Canadian Centre for Cyber Security)

Microsoft przejmuje serwery i rozbija RedVDS – jak działała abonamentowa platforma „cybercrime-as-a-service”

Wprowadzenie do problemu / definicja luki

RedVDS nie był „kolejnym botnetem” ani pojedynczą grupą APT. To model biznesowy: tani, abonamentowy dostęp do jednorazowych maszyn Windows, które cyberprzestępcy wykorzystywali jako infrastrukturę do phishingu, BEC (Business Email Compromise), przejęć kont i oszustw finansowych. Microsoft opisuje RedVDS jako element rosnącego ekosystemu cybercrime-as-a-service, gdzie przestępcy kupują gotowe usługi, zamiast budować zaplecze samodzielnie.

Klucz: taka „hurtowa” infrastruktura obniża próg wejścia. Za kwoty rzędu 24 USD/mies. można było uruchamiać operacje na skalę masową, płacąc kryptowalutami i redukując ślady.

W skrócie

  • Microsoft ogłosił skoordynowane działania prawne w USA oraz – po raz pierwszy w tym typie sprawy – w Wielkiej Brytanii, równolegle z operacją z udziałem organów ścigania (w tym niemieckich) i Europolu.
  • Przejęto kluczową infrastrukturę i zajęto dwie domeny obsługujące marketplace oraz portal klientów RedVDS.
  • Microsoft wiąże RedVDS z ok. 40 mln USD zgłoszonych strat w USA od marca 2025.
  • W „zaledwie jednym miesiącu” ponad 2 600 maszyn RedVDS wysyłało średnio 1 mln phishingowych wiadomości dziennie do klientów Microsoftu.
  • Od września 2025 aktywność wspierana przez RedVDS miała prowadzić do kompromitacji lub oszukańczego dostępu do ponad 191 tys. organizacji globalnie.

Kontekst / historia / powiązania

Z perspektywy obrony (SOC/CSIRT) RedVDS wpisuje się w trend „industrializacji” cyberprzestępczości: atakujący specjalizują się w wąskich fragmentach łańcucha (dostęp, phishing, pranie pieniędzy, infrastruktura), a resztę kupują w modelu usługowym.

Według Microsoft Threat Intelligence RedVDS działał publicznie od 2019 r., oferując serwery w wielu lokalizacjach (m.in. USA, UK, Kanada, Francja, Holandia, Niemcy) i używał kilku domen (m.in. redvds[.]com, redvds[.]pro, vdspanel[.]space).

Microsoft przypisuje rozwój i operowanie marketplace’em aktorowi śledzonemu jako Storm-2470 oraz wskazuje, że z infrastruktury korzystało wiele innych podmiotów (np. Storm-0259 i inne „Stormy”), co sugeruje, że RedVDS był „multitenantem” dla przestępców finansowych, a nie narzędziem jednej kampanii.

W komunikacji Microsoftu przewija się też wątek AI-enabled fraud: RedVDS miał być często łączony z generatywną AI do szybszego typowania celów i tworzenia bardziej wiarygodnych wątków korespondencji, a w części przypadków również z narzędziami deepfake (zamiana twarzy, manipulacja wideo, klonowanie głosu).

Analiza techniczna / szczegóły luki

1) „Disposable Windows” jako produkt

Rdzeniem oferty były tanie serwery Windows dostępne przez RDP z pełnymi uprawnieniami administratora i bez limitów użycia. To idealne środowisko do:

  • masowego wysyłania phishingu (w tym obejścia reputacji źródeł),
  • hostowania stron/landingów, paneli i kitów phishingowych,
  • prowadzenia BEC i „payment diversion” (podmiana rachunków, zmiana danych do przelewu),
  • przejęć kont i dalszego poruszania się po organizacjach.

2) „Palec odcisku” infrastruktury – klonowany obraz Windows

Microsoft opisuje ciekawy aspekt obronny: wiele instancji było tworzonych z jednego, klonowanego obrazu Windows Server 2022, co pozostawiało wykrywalne, powtarzalne artefakty. Przykład: ten sam computer name: WIN-BUNS25TD77J, widoczny m.in. w certyfikatach RDP i telemetrii. Legalni dostawcy chmury zwykle losują/unikalizują takie identyfikatory – tu tego zabrakło.

3) Automatyzacja provisioningu

Operator miał stosować QEMU i sterowniki VirtIO do szybkiego generowania klonów na żądanie klienta. Mechanika była prosta: kopiowanie „master VM” bez poprawnego sysprep/unikalizacji tożsamości systemu, co przyspieszało dostarczanie i obniżało koszty, ale jednocześnie zostawiało spójne ślady.

4) Warstwa utrudniania atrybucji

RedVDS sprzedawano z płatnością w kryptowalutach (Microsoft wymienia m.in. Bitcoin, Litecoin oraz szeroką listę innych) i z narracją o „podmiocie” rzekomo podlegającym prawu Bahamów – klasyczny zabieg zwiększający tarcie dla egzekwowania prawa i identyfikacji operatorów.

Praktyczne konsekwencje / ryzyko

Dlaczego ta historia jest ważna także dla organizacji, które „nie widzą” RedVDS u siebie? Bo usługi tego typu zmieniają ekonomię ataku:

  1. Skalowanie – atakujący nie muszą inwestować w własne serwery/botnety. W komunikacie Microsoftu pada skala: w jeden miesiąc 2 600 maszyn i średnio 1 mln phishingów dziennie do samych klientów Microsoftu.
  2. Szybka rotacja infrastruktury – „jednorazowe” maszyny można porzucić po kampanii, co utrudnia korelację i blokowanie per-IP.
  3. Lepszy social engineering – połączenie hostowanej infrastruktury + generatywnej AI (a czasem deepfake) zwiększa skuteczność BEC, szczególnie przy zmianach danych płatniczych.
  4. Straty finansowe – Microsoft wskazuje ok. 40 mln USD zgłoszonych strat w USA od marca 2025, a przykłady ofiar obejmują m.in. podmiot farmaceutyczny i wspólnotę mieszkaniową.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, które sensownie adresują ten typ zagrożeń (nie tylko RedVDS):

Dla zespołów IT/SOC

  • Wzmocnij polityki SPF/DKIM/DMARC i egzekwuj je (quarantine/reject), a w M365 dopnij ochrony anty-spoofingowe – Microsoft wskazuje, że aktorzy wykorzystywali złożone scenariusze routingu i błędne konfiguracje ochron.
  • Poluj na artefakty RDP/telemetrii: jeśli masz telemetryczne możliwości EDR/XDR, rozważ detekcje oparte o wskazane przez Microsoft charakterystyki klonów (np. powtarzalne elementy połączeń RDP/certyfikatów, fingerprint hosta).
  • Kontrola egress + reputacja: nie opieraj blokad wyłącznie o statyczne listy IP – przy „disposable infra” potrzebujesz korelacji zachowań (nietypowe logowania, masowe wysyłki, anomalie w OAuth).
  • Włącz i wymuś MFA odporne na phishing (FIDO2/passkeys, auth-app z number matching) na kontach uprzywilejowanych i finansowych. BEC to gra o przejęcie skrzynki i manipulację płatnością.

Dla finansów, zakupów i operacji

  • Proces „out-of-band verification”: każda zmiana numeru rachunku/beneficjenta musi być potwierdzona innym kanałem (telefon na znany numer, wideoweryfikacja, portal dostawcy).
  • Dwustopniowa autoryzacja przelewów i limity kwotowe z dodatkowymi kontrolami dla „pierwszego przelewu na nowy rachunek”.
  • Szkolenia na BEC oparte o realne scenariusze (pilne faktury, zmiany rachunku, „CEO fraud”) – RedVDS był wykorzystywany właśnie do takich schematów.

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

RedVDS warto zestawić z wcześniejszymi „takedownami” w modelu usługowym:

  • Phishing-as-a-Service vs Infrastructure-as-a-Service: przejęcie paneli/phishing kitów (PhaaS) ogranicza „narzędzie”, ale infrastruktura w stylu RedVDS to uniwersalny mnożnik – obsłuży phishing, BEC, hosting scamów i wiele innych działań naraz.
  • Wielu aktorów, jedna platforma: Microsoft wprost wskazuje, że z RedVDS korzystały różne „Stormy”, więc uderzenie w usługę ma szansę ograniczyć działalność całego ekosystemu klientów.
  • Legal + technika: kluczowy jest miks działań prawnych (USA i UK) oraz zajęć infrastruktury/domen, bo bez przejęcia marketplace’u i panelu klienta atakujący zwykle po prostu migrują.

Podsumowanie / kluczowe wnioski

Rozbicie RedVDS pokazuje, że współczesna cyberprzestępczość coraz częściej działa jak SaaS: tanio, masowo i z automatyzacją. Dla obrońców najważniejsze są dwa wnioski:

  1. Nie walczysz tylko z „atakującym”, ale z jego łańcuchem dostaw. Uderzenie w infrastrukturę-usługę może obniżyć tempo i skalę wielu kampanii naraz.
  2. BEC i phishing nie znikną po jednym takedownie. Trzeba domykać procesy (weryfikacja płatności) i technikę (MFA odporne na phishing, ochrona przed spoofingiem, detekcje anomalii).

Źródła / bibliografia

  1. Microsoft – Microsoft disrupts global cybercrime subscription service… (14 stycznia 2026) (The Official Microsoft Blog)
  2. Microsoft Threat Intelligence – Inside RedVDS: How a single virtual desktop provider fueled worldwide cybercriminal operations (14 stycznia 2026) (Microsoft)
  3. BleepingComputer – Microsoft seizes servers, disrupts massive RedVDS cybercrime platform (15 stycznia 2026) (BleepingComputer)
  4. Microsoft News (EMEA, DE) – komunikat prasowy dot. RedVDS (styczeń 2026) (Source)
  5. CyberScoop – kontekst współpracy z organami ścigania i Europolem (14 stycznia 2026) (CyberScoop)

UAT-8837: chińsko-powiązany aktor APT poluje na dostęp początkowy w sektorach infrastruktury krytycznej w Ameryce Północnej

Wprowadzenie do problemu / definicja luki

Cisco Talos opisuje UAT-8837 jako aktora APT o średnim poziomie pewności powiązań z Chinami, którego główną rolą wydaje się być pozyskiwanie dostępu początkowego (initial access) do organizacji o wysokiej wartości — a niekoniecznie prowadzenie pełnej kampanii destrukcyjnej czy ransomware. To ważne rozróżnienie: initial-access skupia się na wejściu, rozpoznaniu, kradzieży poświadczeń i „poręczach” do ponownych wejść, często przygotowując grunt pod kolejne etapy działań (także innych zespołów).

W tle pojawia się też wątek eksploatacji podatności CVE-2025-53690 (Sitecore, deserializacja ViewState), co sugeruje dostęp do świeżych technik/łańcuchów eksploatacyjnych i sprawność w szybkim monetyzowaniu błędów w systemach publicznie wystawionych.

W skrócie

  • Kto? UAT-8837 — Talos: medium confidence China-nexus APT.
  • Kogo atakuje? Od co najmniej 2025 r. wyraźny fokus na organizacjach z obszaru infrastruktury krytycznej w Ameryce Północnej.
  • Jak wchodzi? Eksploatacja podatnych serwerów (n-day i zero-day) oraz użycie przejętych poświadczeń.
  • Co robi po wejściu? Recon + kradzież informacji o domenie/AD + budowa wielu kanałów dostępu, głównie narzędziami open-source (Earthworm, SharpHound, DWAgent, Certipy itd.).
  • Detekcja/coverage: Talos podaje m.in. sygnaturę ClamAV (Win.Malware.Earthworm) i zestaw SID-ów Snort.
  • IOC: Talos publikuje hashe narzędzi oraz adresy IP infrastruktury (przykłady niżej).

Kontekst / historia / powiązania

Talos wskazuje na nakładanie się TTP UAT-8837 z innymi grupami z „chińskiego ekosystemu” (China-nexus), ale jednocześnie zaznacza medium confidence — co w praktyce oznacza: są przesłanki behawioralne i operacyjne, jednak atrybucja nie jest przedstawiona jako „zamknięta”.

Warto też zauważyć, że CVE-2025-53690 ma dobrze udokumentowany kontekst operacyjny: w analizie Google Cloud/Mandiant opisano realne nadużycia ViewState prowadzące do RCE w określonych wdrożeniach Sitecore (m.in. przypadki użycia przykładowego machine key z historycznych guide’ów).

Analiza techniczna / szczegóły luki

Wejście: podatności + konta

Talos opisuje dwa dominujące wektory initial access:

  1. Eksploatacja serwerów (w tym przypadek CVE-2025-53690).
  2. Użycie skompromitowanych poświadczeń.

Wczesny recon i „hands-on-keyboard”

Po uzyskaniu przyczółka operatorzy wykonują klasyczny zestaw komend rozpoznawczych (procesy, połączenia, użytkownicy, host, sesje) i przechodzą do działań interaktywnych na hoście (cmd.exe).

Istotny detal: Talos widzi wyłączanie mechanizmu RestrictedAdmin dla RDP poprzez modyfikację rejestru (po to, by ułatwić pozyskanie/wykorzystanie poświadczeń przy zdalnym dostępie).

Staging: gdzie lądują narzędzia

Talos wskazuje katalogi intensywnie wykorzystywane do „magazynowania” artefaktów:

  • C:\Users\<user>\Desktop\
  • C:\Windows\Temp\
  • C:\Windows\Public\Music

Toolchain: narzędzia i ich rola

UAT-8837 bazuje w dużym stopniu na narzędziach publicznych i miesza warianty, gdy są blokowane przez EDR/EPP (Talos wprost sugeruje „cycling” wersji narzędzi).

Najważniejsze elementy łańcucha po kompromitacji (wg Talos):

  • GoTokenTheft – kradzież tokenów dostępu i wykonywanie działań z podniesionymi uprawnieniami (Talos opisuje lokalizację i kontekst użycia).
  • Earthworm – tunelowanie/ruch typu reverse tunnel, wystawianie zasobów wewnętrznych na infrastrukturę atakującego (Talos podaje przykładowe komendy reverse socks/tunnel).
  • DWAgent – zdalna administracja, utrzymanie dostępu i „dropowanie” kolejnych elementów.
  • SharpHound + Certipy – rozpoznanie AD i elementy nadużyć wokół AD/PKI.
  • Impacket / Invoke-WMIExec / GoExec – próby zdalnego wykonania i lateral movement (w tym WMI/DCOM).
  • Rubeus – zestaw narzędzi do nadużyć Kerberos.

Recon domeny i AD

Talos pokazuje zestawy komend typu net group, nltest, setspn, a także wykorzystanie dsquery/dsget do masowego wyciągania atrybutów użytkowników i kont serwisowych — to klasyczny etap przygotowania do eskalacji uprawnień oraz polowania na „bogate” konta.

Utrzymanie dostępu: konta-tylne-furtki

Wprost opisano tworzenie kont domenowych (lub dodawanie istniejących kont do grup) jako kolejnego kanału powrotu do środowiska.

Sygnalizowany wątek supply chain

Talos odnotowuje przypadek eksfiltracji bibliotek DLL powiązanych z produktami ofiary, sugerując ryzyko przyszłego „trojanizowania” lub reverse engineeringu pod kątem kolejnych podatności — to szczególnie niepokojące w kontekście dostawców dla infrastruktury krytycznej.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko trwałej obecności: DWAgent + nowe konta + tunele to przepis na wiele niezależnych ścieżek powrotu.
  2. Ryzyko eskalacji domenowej: recon AD (SharpHound/Certipy/Rubeus) często poprzedza przejęcie kluczowych tożsamości i kontrolę nad środowiskiem.
  3. Ryzyko lateral movement: WMI/DCOM i RDP (wspierane zmianami w rejestrze) zwiększają zasięg intruza.
  4. Ryzyko dla systemów wystawionych do Internetu: CVE-2025-53690 dotyczy Sitecore i została opisana jako podatność typu deserializacja niezaufanych danych prowadząca do code injection; NVD wskazuje też, że CVE znalazło się w katalogu KEV CISA.
  5. Ryzyko łańcucha dostaw / własności intelektualnej: eksfiltracja DLL może zwiastować kolejne kampanie (np. „podmiana” komponentów lub szukanie błędów w produktach).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: ogranicz initial access

  • Zidentyfikuj internet-facing systemy (szczególnie CMS/aplikacje web) i porównaj z podatnościami/konfiguracjami ryzykownymi (dla Sitecore: wątek ViewState/machine key i zalecenia producenta/analizy Mandiant).
  • Wymuś higienę tożsamości: MFA wszędzie, gdzie to możliwe; rotacja haseł uprzywilejowanych; detekcja anomalii logowania i „impossible travel”.

Priorytet 2: polowanie na zachowania i artefakty (TTP > IOC)

  • Monitoruj modyfikacje klucza rejestru dot. DisableRestrictedAdmin (zmiany pod RDP) oraz nietypowe uruchomienia cmd.exe/narzędzi administracyjnych na serwerach aplikacyjnych.
  • Kontrola staging paths: alarmuj na nowe binaria/skrypty w C:\Windows\Temp\ i C:\Windows\Public\Music, zwłaszcza gdy pliki udają .ico/.txt, a w praktyce są wykonywalne.
  • AD hunting: wykrywanie masowego dsquery/dsget, setspn -Q */*, nietypowych zapytań o membershipy i atrybuty kont serwisowych.
  • Account governance: alertuj na net user ... /add /domain, dodawanie kont do lokalnych grup administracyjnych i zmiany w grupach domenowych.

Priorytet 3: detekcje sieciowe i endpointowe

  • Jeśli używasz Snort, zweryfikuj wdrożenie wskazanych SID-ów (Snort 2 i Snort 3) oraz aktualność feedów.
  • Dla AV/anty-malware: Talos wskazuje sygnaturę ClamAV Win.Malware.Earthworm.

Priorytet 4: szybkie sprawdzenie IOC (punkt startowy)

Talos publikuje m.in. hashe i IP powiązane z aktywnością. Przykładowe elementy do natychmiastowego „sweepu”:

  • IP: 74[.]176[.]166[.]174, 20[.]200[.]129[.]75, 172[.]188[.]162[.]183, 4[.]144[.]1[.]47, 103[.]235[.]46[.]102
  • SHA-256 (wybrane):
    • 1b3856e5d8c6a4cec1c09a68e0f87a5319c1bd4c8726586fd3ea1b3434e22dfa (GoTokenTheft)
    • 451e03c6a783f90ec72e6eab744ebd11f2bdc66550d9a6e72c0ac48439d774cd (Earthworm)
    • 5090f311b37309767fb41fa9839d2770ab382326f38bab8c976b83ec727e6796 (SharpHound)
    • 887817fbaf137955897d62302c5d6a46d6b36cb34775e4693e30e32609fb6744 (GoExec)

Uwaga praktyczna: IOC traktuj jako „wskazówkę”, a nie wyrocznię — kluczowe jest wykrywanie zachowań (tunelowanie, recon AD, tworzenie kont, staging w publicznych katalogach), bo UAT-8837 ma obserwowaną skłonność do rotowania narzędzi.

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

  • Model działania „initial access-first” jest charakterystyczny dla kampanii, które chcą utrzymać długoterminowy dostęp i opcjonalnie przekazać „wejście” dalej (wewnętrznie lub zewnętrznie), zamiast od razu wdrażać destrukcję. W materiale Talos to mocno wybrzmiewa: narzędzia, recon, AD, wiele kanałów dostępu.
  • Wysoka adaptacyjność narzędziowa (cycling wariantów pod EDR) to element, który w praktyce obniża skuteczność statycznych blokad hash/opis i podnosi znaczenie telemetrii behawioralnej.
  • CVE-2025-53690 wyróżnia się tym, że doczekało się szczegółowego opisu łańcucha ataku (ViewState, machine key, RCE) oraz zostało ujęte w NVD wraz z informacją o obecności w KEV CISA — co w wielu organizacjach powinno automatycznie windować priorytet patch/mitigation.

Podsumowanie / kluczowe wnioski

UAT-8837 to przykład aktora, który systematyzuje wejście i utrzymanie dostępu, a po kompromitacji szybko przechodzi do rekonesansu i „porządkowania” Active Directory pod dalsze operacje. Jeśli Twoja organizacja ma elementy łańcucha dostaw dla infrastruktury krytycznej (lub sama do niej należy), ten profil działań jest szczególnie ryzykowny: już sama kradzież konfiguracji, poświadczeń i komponentów (np. DLL) może stworzyć warunki pod kolejne fale ataków.

Najbardziej opłacalne działania obronne to: twarde ograniczenie initial access (patch + redukcja powierzchni + tożsamość), detekcja zachowań w AD i na serwerach, oraz szybkie „sweepy” IOC jako wsparcie, nie fundament strategii.

Źródła / bibliografia

  1. Cisco Talos: UAT-8837 targets critical infrastructure sectors in North America (15 stycznia 2026). (Cisco Talos Blog)
  2. Google Cloud / Mandiant: ViewState Deserialization Zero-Day Vulnerability in Sitecore Products (CVE-2025-53690) (3 września 2025). (Google Cloud)
  3. NIST NVD: CVE-2025-53690 Detail (publikacja 3 września 2025; KEV CISA odnotowane na stronie CVE). (NVD)
  4. Materiał referencyjny nt. sektorów infrastruktury krytycznej (16 sektorów, PPD-21) — kopia treści CISA w formie PDF. (cdn.lawreportgroup.com)