Archiwa: Malware - Strona 148 z 165 - Security Bez Tabu

Hakerzy atakują twórców 3D przez złośliwe pliki Blender (.blend) – kampania ze StealC V2

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa ostrzegają przed trwającą co najmniej od pół roku kampanią wymierzoną w użytkowników Blendera – animatorów, grafików 3D oraz studia gier/VFX. Atakujący publikują na marketplace’ach z assetami 3D (m.in. CGTrader) spreparowane projekty .blend z ukrytymi skryptami Pythona. Po otwarciu w Blenderze – jeśli włączona jest opcja „Auto Run Python Scripts” – skrypty uruchamiają łańcuch infekcji, który finalnie dostarcza infostealera StealC V2. Kampania jest wiązana ze środowiskiem rosyjskojęzycznych cyberprzestępców.

W skrócie

  • Wektor wejścia: złośliwe projekty .blend z osadzonym Pythonem (np. zmodyfikowany Rig_Ui.py). Po otwarciu uruchamia się łańcuch pobierania i egzekucji.
  • Ładunek końcowy: StealC V2 – nowa generacja infostealera kradnącego dane z przeglądarek (23+), wtyczek, komunikatorów, portfeli krypto i klientów VPN. Często omija systemy ustawione na języki WNP.
  • Trwałość i C2: skróty LNK w autostarcie Windows i infrastruktura Pyramid C2; pośrednie etapy hostowane m.in. przez Cloudflare Workers.
  • Zakres nadużycia: pliki dystrybuowane na popularnych serwisach z modelami 3D; celem są indywidualni twórcy i firmy (studia gier/VFX).
  • Czynnik ryzyka: domyślna/świadomie włączona funkcja Auto Run Python Scripts w Blenderze (zabezpieczenie istnieje, ale bywa wyłączane dla wygody).

Kontekst / historia / powiązania

StealC pojawił się na forach przestępczych na początku 2023 r., a StealC V2 (2025) znacząco rozszerzył funkcje kradzieży i stealth. Autorzy i operatorzy zwykle wykluczają systemy z językami rosyjskim/ukraińskim/białoruskim/kazachskim/uzbeckim, co jest typowe dla rodzin malware wywodzących się z kręgu WNP. Morphisec łączy obecną kampanię z wcześniejszymi działaniami wykorzystującymi Pyramid C2 i podszywanie się pod Electronic Frontier Foundation.

Analiza techniczna / szczegóły luki

1) Osadzony Python w .blend
Pliki .blend mogą zawierać skrypty Pythona w bpy.data.texts. Jeśli w Blenderze aktywna jest Auto Run Python Scripts, skrypt uruchamia się automatycznie po otwarciu projektu. Blender ma mechanizmy ostrzegania/ufania źródłom, ale wielu użytkowników włącza automatyczne uruchamianie ze względów produkcyjnych.

2) Łańcuch infekcji (przykład z próbki Morphisec):

  • złośliwy Rig_Ui.py pobiera loader z domeny na Cloudflare Workers,
  • uruchamiany jest etap PowerShell,
  • pobierane są dwa archiwa ZIP (m.in. z adresów HTTP v4),
  • rozpakowane komponenty instalują skrót .lnk do folderu Startup (trwałość),
  • następnie pobierany jest właściwy ładunek oraz moduły przez Pyramid C2 (szyfrowanie ChaCha20).

3) Zdolności StealC V2:

  • kradzież danych z 23+ przeglądarek, ponad 100 rozszerzeń/wtyczek, 15+ portfeli kryptowalut, komunikatorów (Telegram/Discord), klientów VPN i poczty, z dodatkowymi technikami obejścia UAC, screenshoty wielomonitorowe, panel C2 z builderem, protokół JSON.

4) Wnioski dla obrony
Łańcuch nadużywa w pełni „legalnej” funkcji automatyzacji Blendera, więc AV/EDR mogą widzieć jedynie „zaufany” proces użytkownika (Blender → python → powershell). Krytyczne są reguły EDR dla ładowania PowerShell z kontekstu aplikacji kreatywnej, detekcja tworzenia LNK w Autostarcie i połączeń do znanych wskaźników kampanii.

Praktyczne konsekwencje / ryzyko

  • Kradzież tożsamości i tajemnic przedsiębiorstwa: wyciek haseł, sesji, tokenów SSO, dostępów do repozytoriów (Git), menedżerów projektów, narzędzi produkcyjnych.
  • Łańcuchowe naruszenia w studiach gier/VFX: przejęte konta repo i render farm mogą ułatwić supply-chain (np. trojanizacja assetów, buildów). (Wniosek na bazie profilu StealC V2 i celu kampanii.)
  • Straty finansowe: kradzież krypto/monetyzacja danych przeglądarkowych; ryzyko dalszej infekcji loaderami przez moduł StealC.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników Blendera i zespołów artystycznych

  1. Wyłącz „Auto Run Python Scripts” (Preferences → Security/Scripting). Włączaj tylko dla zaufanych plików/ścieżek.
  2. Włącz „Trusted Source” per-plik zamiast globalnego Auto Run; korzystaj z ostrzeżeń bezpieczeństwa Blendera (prompt przy otwieraniu).
  3. Otwieraj obce .blend w piaskownicy (VM bez dostępu do przeglądarki/portfeli; brak mapowania folderów profilu). (Dobre praktyki)
  4. Sprawdzaj zawartość Text Editor w Blenderze – szukaj nietypowych skryptów (np. nietypowy Rig_Ui.py). (Dobre praktyki)

Dla SOC/Blue Team

  1. Reguły detekcji:
    • „Blender.exe → python.exe → powershell.exe” (nietypowe drzewo procesów),
    • tworzenie plików .lnk w %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\,
    • ruch do domen Cloudflare Workers z nietypowych narzędzi graficznych; koreluj z IOCs z raportu Morphisec.
  2. Kontrola skryptów: AppLocker/SRPs/WDAC – blokuj PowerShell w trybie pełnym dla procesów Blendera na stacjach artystycznych; egzekwuj Constrained Language Mode dla kont nieuprzywilejowanych. (Dobre praktyki)
  3. Higiena przeglądarek: wymuszaj passkeys/WebAuthn, menedżery haseł z izolacją, kasowanie tokenów przeglądarki po renderach w VM. (Dobre praktyki)
  4. Threat intel & hunting: importuj wskaźniki (IP/URL/hashe) z publikacji Morphisec; monitoruj wzorce Pyramid C2.
  5. Segmentacja stanowisk kreatywnych: odseparuj je od zasobów krytycznych (CI/CD, repo, sekretów); używaj kont bez praw lokalnego admina. (Dobre praktyki)

Różnice / porównania z innymi przypadkami

Nadużywanie automatyzacji w aplikacjach kreatywnych bywało obserwowane (makra, skrypty w plikach projektowych), jednak w Blenderze specyficzna jest łatwość osadzania i autostartu Pythona w .blend. W porównaniu z klasycznymi makrami Office, tutaj barierą jest tylko preferencja Auto Run – gdy zostanie włączona (często „dla wygody”), wektor staje się „kliknij i zainfekuj”. StealC V2 dodatkowo zwiększa ryzyko, bo działa zarówno jako infostealer, jak i loader do kolejnych ładunków.

Podsumowanie / kluczowe wnioski

  • Złośliwe pliki .blend to realny, aktywny wektor ataku na twórców 3D i studia gier/VFX.
  • Krytycznym „bezpiecznikiem” jest wyłączenie Auto Run Python Scripts i ścisła higiena pracy z assetami zewnętrznymi.
  • Kampania wykorzystuje dojrzały ekosystem kradzieżowy StealC V2 oraz sprytne „legitne” ścieżki wykonania (Python/PowerShell), co utrudnia detekcję bez reguł behawioralnych.

Źródła / bibliografia

  1. Morphisec: „Thwarts Russian-Linked StealC V2 Campaign Targeting Blender Users via Malicious .blend Files”, 24 listopada 2025 – szczegółowy łańcuch ataku, IOCs, Pyramid C2. (Morphisec)
  2. Recorded Future News / The Record: „Hackers exploit 3D design software to target game developers, animators”, 26 listopada 2025 – kontekst kampanii i cele. (The Record from Recorded Future)
  3. Blender Manual: „Scripting & Security – Auto Run Python Scripts” – opis mechanizmów bezpieczeństwa i zaufanych źródeł. (Blender Documentation)
  4. Picus Security: „StealC v2 Malware Enhances Stealth and Expands Data Theft Features”, 31 maja 2025 – zdolności StealC V2 i profil ofiary/wykluczenia językowe. (picussecurity.com)
  5. BleepingComputer: „Malicious Blender model files deliver StealC infostealing malware”, 2 dni temu – potwierdzenie łańcucha i nadużycia Auto Run. (BleepingComputer)

Microsoft ostrzega: agentowe funkcje AI w Windows 11 wprowadzają nowe ryzyka bezpieczeństwa

Wprowadzenie do problemu / definicja luki

Microsoft rozpoczął testy eksperymentalnych funkcji agentowych w Windows 11 (m.in. agent workspace i Copilot Actions). Firma jednocześnie ostrzega, że nieprawidłowe zabezpieczenie agentów może przynieść więcej szkód niż korzyści—w tym eksfiltrację danych i instalację złośliwego oprogramowania. Funkcje te są wyłączone domyślnie i przeznaczone dla świadomych ryzyk użytkowników/administratorów.

W skrócie

  • Agent workspace to odizolowana przestrzeń systemowa, w której agent działa na własnym koncie i z ograniczonym dostępem do plików/aplikacji; dostęp rozszerzany jest wyłącznie za zgodą użytkownika.
  • Najistotniejsze nowe wektory to cross-prompt injection (XPIA), błędy uprawnień oraz brak containmentu działań agenta. Microsoft definiuje zasady bezpieczeństwa i prywatności (m.in. least privilege, nadzór i audyt niepodważalny) jako warunek korzystania z funkcji.
  • Copilot Actions zaczęło trafiać do Windows Insiders 17 listopada 2025 r. i korzysta z agent workspace do działań na lokalnych plikach.
  • Windows wzmacnia także warstwę protokołu Model Context Protocol (MCP)—z kontrolami proxy, autoryzacją narzędzi i wymogiem podpisu kodu—aby ograniczać ryzyka agentów i „tool poisoning”.

Kontekst / historia / powiązania

Artykuł SecurityWeek z 24 listopada 2025 r. podsumowuje komunikaty Microsoftu: agent workspace działa w osobnej sesji Windows równolegle do sesji użytkownika, a włączenie funkcji tworzy konta agentów i umożliwia aplikacjom agentowym (np. Copilot) żądanie dostępu do folderów użytkownika (Dokumenty, Pobrane, Pulpit, Muzyka, Obrazy, Wideo).
Dokumentacja Microsoftu (zaktualizowana 17–18 listopada 2025 r.) rozwija zasady bezpieczeństwa, transparentności i kontroli użytkownika, a wpis na Windows Insider Blog potwierdza stopniowy rollout Copilot Actions w kanale Insider.
Równolegle, w maju 2025 r. Microsoft ogłosił wzmacnianie MCP jako warstwy interoperacyjnej dla agentów—z akcentem na proxy egzekwujące polityki, audyt i centralny rejestr serwerów MCP spełniających kryteria bezpieczeństwa.

Analiza techniczna / szczegóły luki

Izolacja i tożsamość

  • Każdy agent działa na oddzielnym koncie standardowym; umożliwia to odrębne polityki i jasne granice uprawnień. Działania agenta są odróżnialne od działań użytkownika.
  • Agent workspace to „lekka” sesja równoległa, zapewniająca runtime isolation i ograniczoną widoczność pulpitu użytkownika; efektywniejsza niż pełna maszyna wirtualna, ale oparta o uznane granice bezpieczeństwa Windows.

Uprawnienia i dostęp do danych

  • Dostęp do plików jest grantowany explicite; początkowo agent może sięgać tylko do znanych folderów użytkownika i zasobów dostępnych dla wszystkich kont. Rozszerzenia wymagają autoryzacji.

Nadzór i audyt

  • Microsoft wymaga możliwości nadzoru planu i kroków agenta, dodatkowych potwierdzeń przy wrażliwych operacjach oraz logów odpornych na manipulacje (tamper-evident audit log).

Nowe wektory ataku (przykłady)

  • Cross-Prompt Injection (XPIA): złośliwa treść w dokumentach/elementach UI może nadpisać instrukcje agenta i skutkować np. eksfiltracją danych lub instalacją malware.
  • Tool/MCP poisoning i luki autoryzacji: niezweryfikowane serwery MCP, słabe uwierzytelnienie lub wycieki poświadczeń agenta mogą prowadzić do przejęcia pełnej kontroli (RCE) przez błędnie zdefiniowane narzędzia.

Praktyczne konsekwencje / ryzyko

Dla SOC/Blue Team oznacza to nową klasę „użytkowników nie-ludzkich” działających w systemie i wykonujących akcje na danych lokalnych, aplikacjach i usługach. Błędy konfiguracji (zbyt szerokie uprawnienia), brak audytu lub brak rozdzielenia tożsamości mogą umożliwić:

  • eskalację uprawnień przez agenta lub jego narzędzia,
  • nieautoryzowany dostęp do danych wrażliwych i ich wypływ,
  • trwałą persystencję i lateral movement w sieci przez łańcuch agent → narzędzie → aplikacja.
    Ryzyka te Microsoft samodzielnie wymienia jako kluczowe i adresuje mechanizmami least-privilege, kontroli użytkownika i izolacji w Windows 11.

Rekomendacje operacyjne / co zrobić teraz

  1. Włączaj funkcje agentowe tylko celowo (domyślnie są wyłączone). Zanim włączysz „Experimental agentic features”, zdefiniuj scopingi uprawnień i ownera agenta.
  2. Tożsamość i dostęp
    • Traktuj konta agentów jak konta techniczne: least-privilege, brak praw admina, TTL dla przyznanych dostępów, regularny przegląd ACL.
  3. Segmentacja i hardening
    • Ogranicz dostęp agent workspace do minimalnego zestawu folderów/aplikacji; rozważ aplikacje instalowane „per-user”, by nie dziedziczyły ich wszystkie konta.
  4. Nadzór i audyt
    • Wymuś HITL dla wrażliwych operacji; integruj logi agenta z SIEM; ustaw alerty na działania wysokiego ryzyka (masowe kopiowanie/archiwizacje, instalacje binariów, modyfikacje polityk).
  5. Higiena treści i XPIA
    • Skany i sanitizacja otwieranych przez agentów dokumentów/stron; ogranicz automatyczne wykonywanie „planów” na treściach pochodzących z niezaufanych źródeł. (Microsoft podkreśla XPIA jako zagrożenie nr 1 dla agentów).
  6. Łańcuch narzędzi (MCP)
    • Dopuszczaj wyłącznie podpisane i zweryfikowane serwery MCP; egzekwuj autoryzację client–tool i rejestrowanie akcji przez warstwę proxy. Unikaj „dzikich” narzędzi bez deklaracji uprawnień.
  7. Testy bezpieczeństwa
    • Zaplanuj red teaming agentów: scenariusze XPIA, „tool poisoning”, wycieki tokenów; testuj przechwytywanie i weryfikację działań przez audyt.

Różnice / porównania z innymi przypadkami

W porównaniu z klasycznymi asystentami (bez zdolności działania w systemie) oraz z automatyzacjami typu RPA, agenci Windows:

  • działają bliżej powierzchni ataku endpointu (klikają, piszą, przewijają jak użytkownik),
  • operują w osobnej sesji i na odrębnym koncie (co daje lepszy containment niż typowe uruchamianie pod kontem użytkownika),
  • wspierają centralne zasady (proxy MCP, podpis kodu, rejestr serwerów), co zbliża je do modeli „zero trust” dla narzędzi.

Podsumowanie / kluczowe wnioski

  • Agentowe AI w Windows 11 to duży skok funkcjonalny—i równie duży skok ryzyka.
  • Microsoft dostarcza ramy bezpieczeństwa: izolacja sesji, osobne konta, least-privilege, autoryzacja, audyt—ale konfiguracja i governance pozostają po stronie organizacji.
  • Kluczem jest świadome włączenie funkcji, ścisłe scope’owanie uprawnień, monitoring i testy ofensywne pod kątem XPIA i łańcucha narzędzi.

Źródła / bibliografia

  1. SecurityWeek — Microsoft Highlights Security Risks Introduced by New Agentic AI Feature (24 listopada 2025). (SecurityWeek)
  2. Microsoft Support — Experimental Agentic Features (akt. 17 listopada 2025). (Microsoft Support)
  3. Microsoft Learn — Securing AI agents on Windows (akt. 18 listopada 2025). (Microsoft Learn)
  4. Windows Experience Blog — Securing the Model Context Protocol (19 maja 2025). (Windows Blog)
  5. Windows Insider Blog — Copilot Actions begins rolling out to Windows Insiders (17 listopada 2025). (Windows Blog)

Matrix Push C2: nowa platforma C2 nadużywa powiadomień przeglądarki do bezplikowych, wieloplatformowych kampanii phishingowych

Wprowadzenie do problemu / definicja luki

Badacze opisali nową usługę przestępczą Matrix Push C2, która zamienia powiadomienia przeglądarki w kanał dowodzenia i kontroli (C2) do dostarczania linków phishingowych i złośliwych przekierowań – bez konieczności początkowej infekcji plikowej. Atak jest wieloplatformowy (działa na dowolnym systemie z przeglądarką), a wektor bazuje na socjotechnice wymuszającej akceptację notyfikacji przez ofiarę. Usługa jest sprzedawana w modelu MaaS (malware-as-a-service) z abonamentami i obsługiwana m.in. przez kanały Telegram.

W skrócie

  • Jak wygląda atak: ofiara jest nakłaniana do włączenia powiadomień strony (złośliwej lub skompromitowanej). Napastnik wysyła potem „systemowo” wyglądające alerty (np. „weryfikacja logowania”, „aktualizacja przeglądarki”), które prowadzą do stron phishingowych lub pobierają malware. Całość dzieje się w przeglądarce, bez wstępnego droppera.
  • Cechy C2: panel www z telemetrią ofiar w czasie rzeczywistym, szablony podszywające się pod MetaMask, Netflix, Cloudflare, PayPal, TikTok, skracacz linków i rejestrowanie rozszerzeń (np. portfeli krypto).
  • Monetyzacja: subskrypcje ok. $150 / m-c, $405 / 3 m-ce, $765 / 6 m-cy, $1,500 / rok; płatność w krypto. Pierwsze obserwacje: początek października 2025 r.
  • Podobieństwo do „ClickFix”: ofiara sama „klika się” w kompromitację, obchodząc klasyczne kontrole.

Kontekst / historia / powiązania

W ostatnich miesiącach widać trend wykorzystywania legalnych funkcji i narzędzi do działań po stronie atakujących. Równolegle raportowano nadużycia narzędzia Velociraptor (DFIR) po włamaniu przez lukę CVE-2025-59287 w WSUS, co pokazuje, że grupy mieszają autorskie frameworki C2 z dostępnymi narzędziami.

Analiza techniczna / szczegóły luki

Jak to działa od strony przeglądarki

  • Push API i Notifications API pozwalają stronom, po wyraźnej zgodzie użytkownika, dostarczać wiadomości nawet, gdy karta nie jest aktywna. Te same mechanizmy – w złych rękach – stają się kanałem C2 do wyświetlania wiarygodnie wyglądających powiadomień na poziomie systemu.
  • Po subskrypcji napastnik może wypychać (push) komunikaty i kierować ofiarę na spreparowane landing pages. Brak wstępnego pliku = bezplikowość (fileless), co utrudnia wykrywanie przez klasyczne AV/EDR.

Funkcje Matrix Push C2 z perspektywy operatora

  • Dashboard kampanii: lista „klientów” (przeglądarek), skuteczność dostarczania, zbieranie interakcji (kliknięcia), wykrywanie rozszerzeń, w tym portfeli krypto.
  • Szablony/tematy: gotowe wzorce podszywające się pod popularne marki poprawiają konwersję phishingu.
  • Skracacz URL z analityką: ułatwia kamuflaż i pomiar skuteczności.

Sprzedaż i model usługowy

  • Dostęp MaaS z cennikiem abonamentowym i komunikacją przez fora/Telegram; kryptopłatności. Pierwsze ślady: październik 2025 r.

Praktyczne konsekwencje / ryzyko

  • Wieloplatformowość: każdy system z przeglądarką i włączonymi powiadomieniami może zostać „klientem” tego C2.
  • Omijanie kontroli: brak droppera i działanie „w kanale” przeglądarki utrudniają korelację alertów i sygnatur.
  • Krótka droga do eskalacji: po pierwszym kliknięciu – kradzież danych logowania, instalacja trwalszego malware, ataki na portfele krypto.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa / IT:

  1. Twarde polityki powiadomień przeglądarki w organizacji:
    • W Chromium/Firefox ograniczaj lub wyłącz globalnie Web Push/Notifications dla niezatwierdzonych domen (policies/GPO, allow-list).
    • Wymuś „quiet notification UI” albo pełny opt-out tam, gdzie to możliwe. (Podstawy działania i ryzyka: MDN).
  2. Higiena uprawnień w przeglądarkach: skryptowe czyszczenie zgód na powiadomienia i Service Workerów dla użytkowników, regularny reset site permissions. (Mechanizmy i best practices: MDN).
  3. Filtracja ruchu wychodzącego i kontrola skracaczy linków (proxy/SWG/NGFW), z korelacją do źródeł powiadomień.
  4. Uwierzytelnianie odporne na phishing (np. FIDO2/WebAuthn, klucze sprzętowe), aby zminimalizować skutki przejęcia haseł.
  5. Playbook IR: dodaj scenariusz „nadużycie powiadomień” – kroki:
    • inwentaryzacja zgód i SW,
    • blokowanie domen kampanii z panelu C2 (IOC z telemetrii),
    • wymuszenie zmiany haseł/oflagowanie sesji. (Opis działania kampanii: BlackFog/THN).

Dla użytkowników końcowych:

  • Nie zezwalaj na powiadomienia z nieznanych stron; cofaj zgody w ustawieniach przeglądarki.
  • Nie klikaj „aktualizacji”/„weryfikacji” z powiadomień – aktualizacje uruchamiaj wyłącznie z menu przeglądarki. (Charakterystyka fałszywych alertów: BlackFog/THN).

Różnice / porównania z innymi przypadkami

  • „ClickFix” vs. Matrix Push C2: oba wektory wykorzystują interakcję użytkownika do ominięcia zabezpieczeń, ale Matrix Push opiera się na legitymizacji kanału powiadomień (UI systemowe), co zwiększa wiarygodność i zasięg (wiele OS/przeglądarek).
  • Nadużycia narzędzi DFIR (Velociraptor): inny etap „kill chain” – po włamaniu (np. przez WSUS CVE-2025-59287) napastnicy używają legalnych narzędzi do C2; w Matrix Push C2 wejście następuje z poziomu przeglądarki bez RCE.

Podsumowanie / kluczowe wnioski

Matrix Push C2 to pragmatyczna ewolucja phishingu: uderza w zaufany interfejs powiadomień, dostarcza fileless i cross-platform kampanie oraz daje operatorom mierzalny, automatyzowany kanał C2. Organizacje powinny ograniczyć Web Push, wdrożyć MFA odporne na phishing i zaktualizować playbooki IR o scenariusze nadużycia powiadomień.

Źródła / bibliografia

  1. The Hacker News — „Matrix Push C2 Uses Browser Notifications for Fileless, Cross-Platform Phishing Attacks”, 22 listopada 2025. (The Hacker News)
  2. BlackFog — „New Matrix Push C2 Abuses Push Notifications to Deliver Malware”, 20 listopada 2025. (BlackFog)
  3. MDN Web Docs — „Push API”. (MDN Web Docs)
  4. MDN Web Docs — „Using the Notifications API”. (MDN Web Docs)
  5. Huntress — „Velociraptor Misuse, Pt. I: WSUS-Up?”, 2 dni temu. (Huntress)

Sturnus — nowy trojan bankowy na Androida przechwytuje wiadomości z WhatsAppa, Telegrama i Signal

Wprowadzenie do problemu / definicja luki

Badacze ThreatFabric opisali nową, prywatnie rozwijaną rodzinę Sturnus — trojana bankowego na Androida, który potrafi obchodzić E2EE komunikatorów (WhatsApp, Telegram, Signal), przechwytując treści po odszyfrowaniu na ekranie. Malware łączy klasyczne techniki bankerów (overlaye HTML, keylogging przez Accessibility) z pełnym przejęciem urządzenia (VNC/hVNC) i aktywną obroną przed usunięciem. Wstępna telemetria wskazuje na celowanie w użytkowników instytucji finansowych w Europie Środkowej i Południowej.

W skrócie

  • Co robi: wykrada dane logowania do bankowości, podsłuchuje czaty po stronie urządzenia, zdalnie steruje telefonem, ukrywa aktywność “czarną nakładką”.
  • Status kampanii: funkcjonalny, lecz w fazie rozwoju/testów; na razie niska skala, celowanie regionalne (EU S/CE).
  • Wejście do systemu: dystrybuowany jako fałszywe APK, m.in. podszywające się pod Google Chrome i “Preemix Box”; wektory prawdopodobne: malvertising/DM.
  • Dlaczego E2EE nie pomaga: Sturnus nie łamie kryptografii — czyta ekran/UI po odszyfrowaniu z użyciem Accessibility i zrzutów ekranu/struktury widoków.

Kontekst / historia / powiązania

Sturnus wpisuje się w trend wzrostu możliwości bankerów na Androida (Herodotus, Crocodilus), którzy łączą Device Takeover z precyzyjnymi overlayami i anti-removal. Media branżowe (SecurityWeek, The Record, BleepingComputer, The Hacker News) potwierdzają wczesną, ale zaawansowaną naturę zagrożenia oraz nacisk na Europę.

Analiza techniczna / szczegóły luki

Łańcuch komunikacji i C2

  • Dwukanałowa łączność: HTTP(S) + WebSocket (WSS); rejestracja klienta, wymiana kluczy RSA→AES, a następnie ruch AES/CBC (IV per wiadomość). WebSocket służy m.in. do sesji VNC.

Pozyskiwanie danych

  • Overlaye HTML (repozytorium szablonów w przestrzeni aplikacji) na popularne aplikacje bankowe; JavaScript bridge do natychmiastowej eksfiltracji. Po zebraniu danych overlay dla danej aplikacji bywa wyłączany, by ograniczyć podejrzenia.
  • Keylogging i obserwacja UI przez Accessibility Service (zdarzenia TYPE_VIEW_*, rekonstrukcja drzewa UI), co pozwala odczytywać tekst oraz kontekst ekranów nawet gdy FLAG_SECURE blokuje standardowy screen capture.

Obchodzenie E2EE komunikatorów

  • Monitorowanie aplikacji pierwszoplanowej i automatyczne włączenie kolekcji UI-tree przy WhatsApp/Telegram/Signal. Dane są widoczne “po stronie ekranu” — po odszyfrowaniu przez legalną aplikację. To nie łamie kryptografii, lecz obchodzi jej model zagrożeń poprzez pełne przejęcie hosta.

Zdalne sterowanie (VNC / hVNC)

  • Dwie ścieżki: strumień obrazu (systemowe przechwytywanie ekranu lub fallback przez Accessibility) oraz sterowanie po drzewie UI (kliki, wprowadzanie tekstu, przewijanie, uruchamianie aplikacji, potwierdzania dialogów). Dostępny czarny overlay ukrywający działania operatora.

Utrzymanie i anty-usuwanie

  • Nadużycie Android Device Administrator; wykrywanie prób odebrania uprawnień i automatyczne wycofywanie użytkownika z ekranu ustawień. Do czasu ręcznego cofnięcia uprawnień odinstalowanie (nawet ADB) jest utrudnione. Rozbudowane monitorowanie środowiska (broadcast receivery, stan baterii/SIM/ADB/SELinux/patch level).

Wejście: fałszywe APK

  • Udokumentowane nazwy pakietów dystrybucyjnych to m.in.:
    • com.klivkfbky.izaybebnx (podszywa się pod Google Chrome)
    • com.uvxuthoq.noscjahae (Preemix Box)
      Dystrybucja prawdopodobnie przez malvertising lub bezpośrednie wiadomości z linkami do APK.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla bankowości mobilnej: przejęcie sesji, autoryzacji i potwierdzeń (MFA) w czasie rzeczywistym; możliwość wykonania przelewów podczas “czarnej nakładki”.
  • Ryzyko dla prywatności i zgodności: masowy exfil treści rozmów z E2EE, kontaktów i metadanych; potencjalne naruszenia RODO, tajemnicy bankowej i poufności klientów.
  • Ryzyko dla zespołów SOC/CSIRT: tradycyjne wskaźniki sieciowe mogą być skąpe (custom protokół, AES/WSS); konieczność telemetrii na poziomie urządzenia i korelacji zdarzeń Accessibility/overlay.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT

  1. Blokada sideloadingu (MDM/Intune/Endpoint Management): wyłącz nieznane źródła instalacji APK; wymuś Google Play Protect.
  2. Polityki uprawnień: audytuj i ogranicz uprawnienia Accessibility (zezwalaj tylko aplikacjom biznesowo uzasadnionym; alerty na nowe zgody).
  3. EDR/Mobile Threat Defense (MTD): wybieraj rozwiązania wykrywające:
    • stałe połączenia WSS do nietypowych domen;
    • intensywne zdarzenia Accessibility i enumerację UI;
    • tworzenie overlayów i długotrwałe “foreground services”.
  4. Higiena MFA: preferuj out-of-band (np. FIDO2/U2F, klucze sprzętowe) zamiast kodów w tej samej przeglądarce/urządzeniu.
  5. Twarde usuwanie: jeśli urządzenie wykazuje symptomy (czarna nakładka, brak możliwości odinstalowania), wejdź do trybu awaryjnego, cofnij Device Admin, następnie odinstaluj; w razie wątpliwości factory reset + odtworzenie zaufanego backupu.
  6. Szkolenia anty-phishingowe: kampanie o fałszywych APK (Chrome/“update systemu”/“Preemix Box”) i malvertisingu.

Dla banków/fintechów

  • Risk-based authentication i detekcje anomalii mobilnych (np. nienaturalne gesty, wzorce VNC, “czarne overlaye”, zmiany Device Admin).
  • App hardening: utrudnianie overlayów, root/jailbreak/emulator detection, “tapjacking protection”, monitorowanie FLAG_SECURE bypass i anomalii Accessibility.
  • Fraud analytics: korelacja telemetrii transakcyjnej z sygnałami z urządzenia (nagłe wyciszenie UI, brak interakcji człowieka, przewijanie skryptowe).

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do wielu bankerów, Sturnus mocno inwestuje w pełny podwójny kanał C2 (HTTP+WSS) i sterowanie po drzewie UI, co zmniejsza zależność od samego streamingu ekranu i atrybutów wizualnych.
  • Podobnie jak Herodotus/Crocodilus, skupia się na Device Takeover, ale jego monitoring środowiska (SIM/ADB/SELinux/patch level) i rozbudowana obrona Device Admin są ponadprzeciętnie zaawansowane.

Podsumowanie / kluczowe wnioski

Sturnus nie łamie kryptografii E2EE — omija ją, kompromitując host i odczytując to, co widzi użytkownik. Dla obrony oznacza to przesunięcie nacisku z IoC sieciowych na behawior urządzenia: overlaye, nadużycia Accessibility, uprzywilejowania Device Admin i nietypowe sesje WSS/VNC. Wykrycie na wczesnym etapie i dyscyplina instalacyjna (zakaz sideloadingu) będą kluczowe.

Źródła / bibliografia

  1. ThreatFabric — Sturnus: Mobile Banking Malware bypassing WhatsApp, Telegram and Signal Encryption (20 listopada 2025). (ThreatFabric)
  2. SecurityWeek — New Sturnus Banking Trojan Targets WhatsApp, Telegram, Signal Messages (20 listopada 2025). (SecurityWeek)
  3. The Hacker News — New Sturnus Android Trojan Quietly Captures Encrypted Chats and Hijacks Devices (20 listopada 2025). (The Hacker News)
  4. BleepingComputer — Multi-threat Android malware Sturnus steals Signal, WhatsApp messages (20 listopada 2025). (Bleeping Computer)
  5. The Record — New Android malware can capture private messages, researchers warn (20 listopada 2025). (The Record from Recorded Future)

EdgeStepper: implant AitM przekierowujący DNS, który podszywa się pod aktualizacje oprogramowania (PlushDaemon)

Wprowadzenie do problemu / definicja luki

Badacze ESET opisali nowy implant sieciowy EdgeStepper, używany przez grupę APT PlushDaemon (powiązaną z Chinami) do ataków adversary-in-the-middle (AitM). Narzędzie działa na urządzeniach brzegowych (np. routerach) i przekierowuje cały ruch DNS na kontrolowany przez atakujących „węzeł przechwycenia”, który podmienia adresy serwerów aktualizacji popularnych aplikacji. W efekcie legalny mechanizm update’u pobiera złośliwe pierwsze etapy (LittleDaemon, DaemonicLogistics), a następnie właściwy backdoor SlowStepper. Informacje ujawniono 19 listopada 2025 r.

W skrócie

  • Wejście: kompromitacja urządzenia sieciowego ofiary (eksploatacja podatności lub słabe hasła), instalacja EdgeStepper.
  • Technika: przechwycenie i przekierowanie DNS (udp/53) do złośliwego węzła; selektywne odpowiadanie na domeny aktualizacji (np. Sogou Pinyin).
  • Łańcuch infekcji: LittleDaemon → DaemonicLogistics → SlowStepper (zbieranie informacji, eksfiltracja, rozbudowany „toolkit”).
  • Zasięg: cele w Chinach, Hongkongu, Tajwanie, Kambodży, Korei Płd., USA, Nowej Zelandii (co najmniej od 2018 r.).
  • Precedensy: PlushDaemon wcześniej zrealizował atak łańcucha dostaw na VPN IPany (2023). Podobną taktykę AitM DNS stosowały Blackwood/NSPX30 i Evasive Panda.

Kontekst / historia / powiązania

Przechwytywanie aktualizacji poprzez manipulację DNS to trend widoczny w wielu klastrach APT powiązanych z Chinami. ESET opisywał Blackwood/NSPX30 (AitM aktualizacji) oraz przypadki, w których Evasive Panda (StormBamboo) kompromitowała operatora ISP i zatruwała DNS na poziomie sieci, aby dostarczać backdoory do systemów Windows i macOS. Z kolei u PlushDaemon ten wektor stał się głównym mechanizmem dostępowym, uzupełnianym o exploity w serwerach www i kampanie supply-chain (IPany).

Analiza techniczna / szczegóły luki

Architektura EdgeStepper

  • Implant napisany w Go (oparty o framework GoFrame) jako ELF dla MIPS32 – targetem są typowe platformy routerowe/edge. Konfigurację odszyfrowuje z /etc/bioset.conf algorytmem AES-CBC z „stałym” kluczem/IV związanym z GoFrame (ciąg znaków „I Love Go Frame!”).
  • Przykładowa konfiguracja zawiera sekcję: [cheat] toPort = 1090 host = "ds20221202.dsc.wcsset[.]com" (w kodzie występuje też blok z test.dsc.wcsset[.]com, historycznie wskazujący na adres 47.242.198[.]250 – węzeł przechwycenia).

Mechanizm przekierowania DNS

  • Moduł Ruler wstawia reguły iptables przekierowujące cały UDP/53 → lokalny port (np. 1090), gdzie działa proxy DNS implant. Pakiety są następnie forwardowane do „malicious DNS node” wskazanego przez konfigurację.

Selektywna podmiana aktualizacji

  • „Złośliwy DNS” rozpoznaje domeny kanałów update (np. info.pinyin.sogou.com, ime.sogou.com, mobads.baidu.com) i zwraca adres węzła hijacking, który instruuje aplikację do pobrania DLL „popup_4.2.0.2246.dll” – to LittleDaemon.

Łańcuch ładunków

  • LittleDaemon: 32-bit PE (DLL/EXE), bez trwałości; komunikuje się z węzłem przechwycenia, pobiera DaemonicLogistics.
  • DaemonicLogistics: shell-code/position-independent, interpretuje kody odpowiedzi HTTP jako komendy (np. 200/207), pobiera pliki (file6.bdat, file2.bdat), a docelowo dostarcza SlowStepper.
  • SlowStepper: rozbudowany backdoor (C++ + moduły Python/Go, >30 komponentów), z C2 inicjalizowanym m.in. przez rekordy DNS TXT (7051.gsm.360safe[.]company), z szerokimi zdolnościami eksfiltracji (przeglądarki, komunikatory, multimedia).

Praktyczne konsekwencje / ryzyko

  • Omijanie kontroli endpointowych: atak odbywa się przed hostem – na urządzeniu brzegowym lub w ścieżce sieciowej. Kontrole EDR/AV mogą nie zadziałać przed pobraniem ładunku przez „legalny” proces aktualizatora.
  • Zaufanie do update’ów: kompromitacja kanału aktualizacji legalnych aplikacji (często popularnych, jak klawiatury czy pakiety biurowe) radykalnie podnosi współczynnik sukcesu infekcji i ułatwia lateral movement.
  • Trudna detekcja w DNS: EdgeStepper działa jak transparentny proxy DNS – z perspektywy hostów zapytania wyglądają zwyczajnie, tylko ścieżka odpowiedzi jest podmieniana.
  • Ryzyko sektorowe: według telemetryki ESET ofiary to m.in. uczelnie, przemysł elektroniczny i motoryzacyjny, oddziały firm w regionie APAC oraz pojedyncze podmioty w USA/NZ.

Rekomendacje operacyjne / co zrobić teraz

Higiena urządzeń brzegowych

  1. Aktualizacje firmware/routerów i wymuszenie MFA + silnych, unikalnych haseł do paneli admina; wyłącz zdalny dostęp administracyjny z Internetu (lub ogranicz go przez VPN/SSH z listy dozwolonych).
  2. Monitoring reguł netfilter/iptables: wykrywaj anomalie typu PREROUTING -p udp --dport 53 -j REDIRECT --to-port 1090 oraz nietypowe procesy nasłuchujące na udp/1090. (Dopasowane do artefaktów EdgeStepper).
  3. Kontrola konfiguracji DNS na brzegach: wymuszaj rezolwery autoryzowane/pinowane (np. DoT/DoH do organizacyjnego resolwera z certificate pinning na kliencie). Uwaga: jeśli implant przechwytuje port 53 na urządzeniu, DoH/DoT z hosta może ograniczyć skuteczność ataku, o ile nie jest breakowany na bramie.

Segmentacja i egress
4. Blokady egress DNS: zezwalaj wyłącznie na DNS z zaufanych resolverów (kontrolowanych przez SOC), drop dla ruchu DNS od hostów bezpośrednio do Internetu.
5. Listy wskaźników: monitoruj/blokuj domeny *.dsc.wcsset[.]com, IP 47.242.198[.]250 (historyczny hijacking node), ścieżki HTTP ime.sogou.com/update/*, oraz niestandardowe DLL np. popup_4.2.0.2246.dll. (Aktualizuj IOC wg najnowszych publikacji).

Kontrole hostowe
6. AppControl/Allow-list dla updaterów: egzekwuj TLS z weryfikacją certów/pinningiem i blokuj połączenia HTTP plaintext w procesach aktualizujących (częsty wektor w opisanym łańcuchu).
7. EDR/YARA: reguły na artefakty LittleDaemon/DaemonicLogistics/SlowStepper; heurystyki na anomalię korzystania z PerfWatson.exe/DLL sideloadingu (znane z kompromitacji IPany).

Detekcja w DNS/NetFlow
8. Anomalie DNS: niespójność odpowiedzi dla domen aktualizacji (częste NXDOMAIN/timeouty, zmiany TTL, brak spójności EDNS), niespodziewane TXT-lookup do *.360safe[.]company itd. (wątek SlowStepper).
9. Telemetryka brzegowa: porównuj sumaryczne QNAME/serwery autorytatywne z referencyjnym resolverem poza siecią (wykrywanie trojanizacji ścieżki).

Procedury
10. Threat hunting: przejrzyj logi od 2019 r. w sieciach o podwyższonym ryzyku (APAC/firmy z chińskojęzycznym łańcuchem dostaw).
11. SBOM/ketchain aktualizacji: wymuś podpisywanie i weryfikację aktualizacji, TLS-pinning oraz re-download fallback wyłącznie z hard-coded domen + cert pinning.

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

  • PlushDaemon / EdgeStepper – przechwycenie przez implant na urządzeniu brzegowym z przekierowaniem całego DNS; multi-stage (LittleDaemon → DaemonicLogistics → SlowStepper).
  • Blackwood / NSPX30 – także AitM aktualizacji, ale inna linia artefaktów (NSPX30) i odrębne TTP/C2; również ataki na popularne chińskie oprogramowanie.
  • Evasive Panda (StormBamboo) – kompromitacja ISP i DNS poisoning na poziomie operatora, trafianie zarówno Windows, jak i macOS; bliskie tematycznie, ale inna infrastruktura i grupa.

Podsumowanie / kluczowe wnioski

EdgeStepper to dojrzały implant AitM dla DNS, który przesuwa punkt przełamania z hosta na urządzenie brzegowe. Dzięki selektywnej podmianie odpowiedzi DNS dla domen aktualizacji atakujący przekształcają zaufany proces update’u w łańcuch infekcji kończący się bogatym funkcjonalnie backdoorem SlowStepper. Organizacje powinny traktować DNS i urządzenia brzegowe jako krytyczny wektor supply-chain, wdrażając monitoring reguł, pinning kanałów update’u, restrykcje egress DNS oraz hunting za IOC wskazanymi przez ESET.

Źródła / bibliografia

  1. The Hacker News – „EdgeStepper Implant Reroutes DNS Queries to Deploy Malware via Hijacked Software Updates”, 19 listopada 2025. (The Hacker News)
  2. ESET WeLiveSecurity – „PlushDaemon compromises network devices for adversary-in-the-middle attacks (EdgeStepper)”, 19 listopada 2025. (We Live Security)
  3. ESET WeLiveSecurity – „PlushDaemon compromises supply chain of Korean VPN service (SlowStepper)”, 22 stycznia 2025. (We Live Security)
  4. ESET WeLiveSecurity – „NSPX30: A sophisticated AitM-enabled implant… (Blackwood)”, 24 stycznia 2024. (We Live Security)
  5. Volexity – „StormBamboo compromises ISP to abuse insecure software update mechanisms”, 2 sierpnia 2024. (Volexity)

TamperedChef: globalna kampania malvertising z fałszywymi instalatorami i podpisanymi certyfikatami

Wprowadzenie do problemu / definicja luki

Trwająca kampania „TamperedChef” dystrybuuje złośliwe oprogramowanie poprzez fałszywe instalatory popularnych narzędzi (np. edytory PDF, czytniki manuali, gry). Atakujący intensywnie wykorzystują malvertising i SEO-poisoning, aby użytkownicy trafiali na przygotowane strony i pobierali „podpisane” aplikacje, które wyglądają i działają jak prawdziwe. Po instalacji utrzymywana jest trwałość i pobierany jest zaciemniony backdoor JavaScript, umożliwiający zdalną kontrolę i kradzież danych. Kampania jest aktywna globalnie i wciąż rozwijana.

W skrócie

  • Wejście: reklamy i wyniki wyszukiwania kierują do domen z pozornie wiarygodnymi instalatorami.
  • Uwiarygodnienie: pliki są podpisane certyfikatami wystawionymi na spółki-wydmuszki (LLC) rejestrowane m.in. w USA; po unieważnieniu certyfikatów operatorzy szybko rotują na kolejne.
  • Trwałość: tworzenie Scheduled Task z task.xml, który cyklicznie uruchamia obfuskowany JS backdoor.
  • C2 / telemetria: aktywność szczególnie widoczna w USA oraz w Europie; infrastruktura oparta o domeny rejestrowane przez Namecheap i ochronę prywatności.
  • Nazewnictwo: ten sam łańcuch ataku bywa raportowany jako TamperedChef lub BaoLoader; część publikacji łączy go z szeroką kampanią EvilAI.

Kontekst / historia / powiązania

Pierwsze szeroko opisywane fale dotyczyły fałszywego „AppSuite PDF Editor” i pokrewnych „PDF/Manual Readerów”, promowanych reklamami Google i podszywających się pod legalne strony. Niezależne analizy (Truesec, Broadcom/Symantec, WithSecure) potwierdzają długofalowy, iteracyjny charakter operacji oraz zmiany w łańcuchu wykonania i infrastrukturze. Część wątków łączona jest z parasolem „EvilAI”, tj. przynętami nawiązującymi do narzędzi AI.

Analiza techniczna / szczegóły kampanii

Łańcuch infekcji

  1. SEO/malvertising → kliknięcie prowadzi do domen-landingów nazwanych podobnie do aplikacji (np. download[.]manualreaderpro[.]com, download[.]anyproductmanual[.]com). Rejestracje przez Namecheap, z ochroną WHOIS i krótkimi okresami ważności.
  2. Instalator (funkcjonalny, z GUI i EULA) po uruchomieniu:
    • odkłada task.xml,
    • tworzy Scheduled Task uruchamiający plik JS z %APPDATA%\Programs\[Nazwa],
    • po instalacji otwiera kartę „thank you” — element socjotechniki.
  3. Backdoor JS: ciężko obfuskowany (np. z użyciem obfuscator.io), zbiera identyfikatory (session/machine ID), szyfruje XOR + Base64 i komunikuje się z C2 po HTTPS; posiada zdolność zdalnego wykonywania poleceń.

Infrastruktura C2
Widziane były zarówno „losowe” subdomeny (api.[losowy].com), jak i nazwy mające mieszać się z ruchem (np. get.latest-manuals[.]com, app.catalogreference[.]com, a także api.mxpanel[.]com, api.mixpnl[.]com).

Certyfikaty i spółki-wydmuszki
Operatorzy uzyskują certyfikaty (w tym EV) dla serii anonimowych firm (np. Native Click Marketing LLC, Pixel Catalyst Media LLC, App Interplace LLC, Unified Market Group LLC), a po odwołaniu podpisów szybko zastępują je nowymi. To zapewnia ciągłość dostaw i „przemysłowy” model operacyjny. Równolegle wcześniejsze fale podpisywano także podmiotami z Malezji (np. ECHO Infini SDN BHD).

Nazwy / warianty
Różni dostawcy używają różnych etykiet: TamperedChef (Acronis, Truesec), BaoLoader (Expel). W praktyce chodzi o tę samą rodzinę taktyk: fałszywe, podpisane aplikacje → trwałość → JS/C2 → kradzież danych/zdalne sterowanie.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych uwierzytelniających (hasła, cookies sesyjne), inwentaryzacja systemu, możliwość doinstalowania kolejnych ładunków (np. ransomware).
  • Bypass zaufania dzięki ważnym podpisom — wysoki współczynnik instalacji przez pracowników.
  • Ryzyko sektorowe: częstsze ofiary w ochronie zdrowia, budownictwie, produkcji (częste poszukiwanie instrukcji/sterowników).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Teamów

  • Dodaj blokady/detekcje dla znanych wzorców domen (np. download.[nazwa-app], api.*.com z listy obserwacji) oraz wskaźników latest-manuals, catalogreference, mxpanel, mixpnl. Monitoruj nowo rejestrowane domeny podobne do tych nazw.
  • Wyszukaj na hostach artefakty Scheduled Tasks tworzone z task.xml oraz ścieżki %APPDATA%\Programs\[Nazwa-fałszywej-aplikacji].
  • Detekcje dla wbudowanego skryptu JS: wywołania WScript, nietypowe rundll32/wscript z argumentami, deobfuskacja ciągów, wzorce XOR + Base64 przed transmisją HTTPS.
  • Reaguj na nietypowe „dziękujemy za instalację” w przeglądarce po instalacji narzędzi biurowych — koreluj z nowymi wpisami zadań.
  • Wprowadź kontrolę aplikacji (wdrażanie tylko z pozytywnej listy wydawców), EDR z regułami na tworzenie zadań z plików XML oraz na procesy potomne instalatorów. (Wnioski z telemetrii i technik TTP).

Dla zespołów IT/bezpieczeństwa

  • Zablokuj instalacje spoza sklepu/portalu firmowego; egzekwuj „znane dobre” certyfikaty (Publisher Allow-List).
  • Wdróż DNS sinkhole/filtry na kategorie malvertising/nowe domeny + reguły detekcji „typosquattingu” na nazwy aplikacji.
  • Szkolenia: ostrzeż użytkowników przed „darmowymi” edytorami PDF/manual readerami z reklam i przypadkowych wyników wyszukiwania.
  • Hunting retroaktywny: sprawdź instalacje od czerwca 2025 r. (szczególnie PDF/Manual Reader, chess/games) oraz nieznanych wydawców z USA/Malezji.

Różnice / porównania z innymi przypadkami

  • Wcześniejsze fale TamperedChef opisywano przy AppSuite PDF Editor z długą zwłoką aktywacji i mieszanym mechanizmem trwałości (rejestr + zadania). Nowszy wariant upraszcza trwałość wyłącznie do Scheduled Task + task.xml i przechodzi na backdoor JS z intensywną obfuskacją.
  • W porównaniu z typowymi loaderami, ten ekosystem skalowalnie rotuje certyfikaty i spółki-wydmuszki, co zwiększa „żywotność” łańcucha dystrybucji.
  • Część vendorów klasyfikuje rodzinę jako BaoLoader — różnice nomenklatury, TTP podobne.

Podsumowanie / kluczowe wnioski

TamperedChef to zindustrializowana kampania łącząca socjotechnikę, podpisy cyfrowe, rotację certyfikatów i złośliwe reklamy. Najbardziej niebezpieczne są wiarygodność (funkcjonalne aplikacje z podpisem), cicha trwałość (Scheduled Task z task.xml) i modułowy backdoor JS. Organizacje powinny bezwzględnie zamykać łańcuch instalacji oprogramowania, monitorować tworzenie zadań z plików XML, a także wdrożyć allow-listing wydawców i hunting IOC pod kątem wymienionej infrastruktury C2.

Źródła / bibliografia

  1. The Hacker News — „TamperedChef Malware Spreads via Fake Software Installers…” (20 listopada 2025). Źródło prasowe z odnośnikami do analizy Acronis. (The Hacker News)
  2. Acronis TRU — „Cooking up trouble: How TamperedChef uses signed apps to deliver stealthy payloads” (19 listopada 2025). Analiza techniczna: task.xml, JS backdoor, C2, certyfikaty/LLC. (Acronis)
  3. Truesec — „TamperedChef: the bad PDF editor” (27 sierpnia 2025). Wczesna fala: AppSuite PDF Editor, certyfikaty z Malezji/USA, mechanizmy trwałości. (Truesec)
  4. Trend Micro — „EvilAI” (11 września 2025). Kontekst kampanii podszywających się pod narzędzia AI/produktywne. (www.trendmicro.com)
  5. WithSecure — „TamperedChef: Malvertising to Credential Theft” (3 października 2025). Ujęcie europejskie i ścieżka kradzieży poświadczeń. (Withsecure Labs)

CVE-2015-5122 — Adobe Flash Player UAF (opaqueBackground)

TL;DR

CVE‑2015‑5122 to krytyczna luka use‑after‑free w Adobe Flash Player (klasa DisplayObject/właściwość opaqueBackground), aktywnie wykorzystywana w 2015 r. m.in. przez zestawy exploitów (Angler, RIG, Neutrino) i kampanie watering‑hole. Daje zdalne wykonanie kodu po wizycie na złośliwej lub skompromitowanej stronie (łańcuch T1189 → T1203), typowo kończąc się uruchomieniem interpretera skryptów/LOLBin z procesu przeglądarki. Dziś Flash jest EOL i globalnie blokowany, ale detekcje nadal mają wartość do wykrywania analogicznych łańcuchów klient‑strona. Patch dla Flash: 18.0.0.209 (APSB15‑18).


Krótka definicja techniczna

CVE‑2015‑5122 to błąd Use‑After‑Free (CWE‑416) w implementacji ActionScript 3 (AS3) Adobe Flash Player, który przy specjalnie spreparowanej zawartości SWF prowadzi do korupcji pamięci i zdalnego wykonania kodu bez interakcji użytkownika poza odwiedzeniem strony. Dotyczy wersji 13.x–18.0.0.203 (Windows/macOS), 11.x–11.2.202.481 (Linux) i Chrome‑Linux do 18.0.0.204; podatność była wykorzystywana w naturze w lipcu 2015 r. (CVSS v3.1: 9.8).


Gdzie występuje / przykłady platform

  • Windows / macOS / Linux (endpointy z przeglądarkami) — wektorem jest załadowanie wtyczki Flash (PPAPI/NPAPI/ActiveX) i wykonanie SWF z exploitami; historycznie obserwowano ładowanie modułów pepflashplayer.dll, NPSWF*.dll, procesy pokrewne (np. plugin‑container.exe / FlashPlayerPlugin_.exe).
  • Active Directory / VDI — ryzyko lateralne, jeśli stacje domenowe/VDI mają przestarzały Flash.
  • Chmury (AWS/Azure/GCP), K8s, ESXi, M365 — sama podatność dotyczy klienta, ale artefakty sieciowe (pobrania .swf z S3/CloudFront) mogą być widoczne w telemetrych chmurowych organizacji hostującej treści.
  • Stan obecny — Adobe zakończyło wsparcie z końcem 2020 r. i blokuje uruchamianie Flash od 12 stycznia 2021 r., lecz „zombie‑instalacje” mogą nadal istnieć w niszach środowisk.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Atakujący dostarcza spreparowany plik SWF, który po załadowaniu przez wtyczkę Flash wyzwala UAF w obsłudze opaqueBackground w klasie DisplayObject. Stage shellcode/ROP przejmuje kontrolę w procesie wtyczki/przeglądarki i uruchamia trwały stage‑2 (np. interpreter skryptów lub „LOLBin”), często po cichu ściągając ładunek. W 2015 r. CVE‑2015‑5122 błyskawicznie trafił do zestawów exploitów (Angler, RIG, Neutrino, Magnitude) i był użyty w watering‑hole przeciw firmie z sektora lotniczego — właśnie dlatego technika była wyjątkowo skuteczna w łańcuchach malvertising i „wejdź‑i‑zainfekuj”.

Łańcuch ATT&CK (częsty):
T1189 (Drive‑by) → T1203 (Exploitation for Client Execution) → uruchomienie interpretera/LOLBin (np. powershell.exe, mshta.exe, rundll32.exe) → T1105 (Ingress Tool Transfer)/C2. (Wzorzec zgodny z analitykami/detection strategies MITRE v18).

Łatanie i reakcje ekosystemu (2015): Adobe wydało poprawkę APSB15‑18 podnosząc Flash do 18.0.0.209 (i 13.0.0.305). Mozilla tymczasowo „soft‑blockowała” wersje do 18.0.0.203.


Artefakty i logi

ŹródłoArtefakt / zdarzenieWartość dla detekcji
Windows SysmonEID 1 Process Create – dziecko powershell.exe, wscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, cmd.exe, msiexec.exe uruchomione przez chrome.exe/msedge.exe/iexplore.exe/firefox.exe/plugin-container.exe/FlashPlayerPlugin_*.exeSilny sygnał post‑eksploitacyjny (client → OS).
EID 3 Network Connection – po podejrzanym procesie (C2/transfer)Korelacja czasowa po EID 1.
EID 7 Image Loaded – załadowanie pepflashplayer.dll / NPSWF*.dllKontekst historyczny (Flash w systemie).
EID 11 FileCreate – drop w %TEMP%/%APPDATA% (EXE/DLL/SCT/VBS)Artefakt płatka.
EID 22 DNS Query – zapytania do rzadkich domen chwilę po wizycie WWWCzęsty sygnał EK/C2.
Windows Security4688 Process CreationAlternatywa gdy brak Sysmon.
Przeglądarka/OSCrash/WER Event 1001 po błędzie wtyczkiUAF bywa poprzedzony niestabilnością.
Proxy/DNS/NGFWŻądania *.swf, nietypowe przekierowania, malvertisingKontekst T1189.
AWS CloudTrail (Data events/S3)GetObject na kluczach *.swf z publicznych bucketów (gdy Twoja organizacja hostuje treści)Do skanów higieny/ekspozycji.
K8s audit / M365[nie dotyczy]Luka dotyczy klienta, nie kontrol‑plane/SaaS.

Detekcja (praktyczne reguły)

Sigma (Windows / process_creation)

title: Browser/Flash Spawning Script Interpreters Or LOLBins
id: 4d9b8f83-7c2b-45b1-9e4b-ffb1b7b31012
status: stable
description: Wykrywa uruchomienie interpreterów/LOLBinów jako dziecka procesu przeglądarki/wtyczki Flash (łańcuch po T1203/CVE-2015-5122).
author: Badacz CVE
logsource:
  category: process_creation
  product: windows
detection:
  parent_browsers:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\iexplore.exe'
      - '\firefox.exe'
      - '\plugin-container.exe'
      - '\FlashPlayerPlugin_32.exe'
      - '\FlashPlayerPlugin_64.exe'
  suspicious_children:
    Image|endswith:
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\cmd.exe'
      - '\bitsadmin.exe'
      - '\certutil.exe'
      - '\msiexec.exe'
  condition: parent_browsers and suspicious_children
fields:
  - User
  - CommandLine
  - ParentCommandLine
  - Image
  - ParentImage
  - ProcessGuid
  - ParentProcessGuid
falsepositives:
  - Aktualizacje/instalatory uruchamiane z przeglądarki przez użytkownika
level: high
tags:
  - attack.t1203
  - attack.t1189

Splunk (Sysmon)

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval parent=lower(coalesce(ParentImage,ParentProcessName)), child=lower(Image)
| where like(parent,"%\\chrome.exe") OR like(parent,"%\\msedge.exe") OR like(parent,"%\\iexplore.exe")
  OR like(parent,"%\\firefox.exe") OR like(parent,"%\\plugin-container.exe") OR like(parent,"%\\flashplayerplugin%")
| where child like("%\\powershell.exe") OR child like("%\\wscript.exe") OR child like("%\\cscript.exe")
  OR child like("%\\mshta.exe") OR child like("%\\rundll32.exe") OR child like("%\\regsvr32.exe")
  OR child like("%\\cmd.exe") OR child like("%\\bitsadmin.exe") OR child like("%\\certutil.exe") OR child like("%\\msiexec.exe")
| stats count min(_time) as first_seen max(_time) as last_seen values(CommandLine) as child_cmd by host, user, parent, child, ParentCommandLine, ProcessGuid, ParentProcessGuid
| convert ctime(first_seen) ctime(last_seen)

KQL (Microsoft Defender for Endpoint / Sentinel)

DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","iexplore.exe","firefox.exe","plugin-container.exe",
                                      "FlashPlayerPlugin_32.exe","FlashPlayerPlugin_64.exe")
| where FileName in~ ("powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe",
                      "regsvr32.exe","cmd.exe","bitsadmin.exe","certutil.exe","msiexec.exe")
| summarize cnt=count(), first=min(Timestamp), last=max(Timestamp),
            make_set(ProcessCommandLine), make_set(InitiatingProcessCommandLine)
          by DeviceName, AccountName, FileName, InitiatingProcessFileName

CloudTrail (S3 data events, higiena własnych zasobów)

Szuka pobrań plików .swf z Twoich bucketów (kontrola ekspozycji/legacy).

fields @timestamp, eventName, requestParameters.bucketName as bucket, requestParameters.key as key, sourceIPAddress, userAgent
| filter eventSource = "s3.amazonaws.com" and eventName = "GetObject"
| filter key like /(?i)\.swf$/
| sort @timestamp desc

Elastic / EQL

process where
  process.parent.name in ("chrome.exe","msedge.exe","iexplore.exe","firefox.exe","plugin-container.exe",
                          "FlashPlayerPlugin_32.exe","FlashPlayerPlugin_64.exe") and
  process.name in ("powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe",
                   "regsvr32.exe","cmd.exe","bitsadmin.exe","certutil.exe","msiexec.exe")

Heurystyki / korelacje (co łączyć)

  • Krótki łańcuch czasowy: wizytę WWW (proxy/DNS) → child process z przeglądarki → ruch wychodzący/C2 → drop w %TEMP%. (Wzorzec MITRE Detection Strategies dla technik klienckich).
  • Rzadkie moduły: ładowanie starych bibliotek Flash (NPSWF*, pepflashplayer.dll) na hostach, gdzie Flash nie powinien istnieć.
  • Domeny jednorazowe/malvertising: przekierowania, iFrame, 302‑cushioning — znane z EK (Angler).
  • WER/crashe po wtyczce tuż przed spawnem interpretera.

False positives / tuning

  • Instalacje/aktualizacje uruchamiane z przeglądarki (np. msiexec.exe po pobraniu legalnego instalatora).
  • Skrypty administracyjne wywoływane z web‑portali korporacyjnych (Self‑Service).
  • Tuning: zawęź do parent=browser/plugin + dziecko z listy + CommandLine z wzorcami web‑download (http, -enc, -w hidden, urlmon, bitsadmin, certutil -urlcache -split) i korelacja DNS/proxy w ±2 min.

Playbook reagowania (IR)

  1. Triage & izolacja hosta (EDR network containment).
  2. Zabezpieczenie artefaktów:
    • Zrzut pamięci podejrzanych procesów (przeglądarka/child).
    • Logi: Sysmon 1/3/11/22, WER 1001, proxy/DNS; Prefetch dla child.
  3. Szybkie IOC sweep: domeny/URL z proxy, hash dropu, ścieżki %TEMP%/%APPDATA%.
  4. Eradykacja: usuń pozostałości, zablokuj domeny/IP, wymuś aktualizację przeglądarek, odinstaluj Flash (jeśli gdzieś jeszcze jest). Adobe blokuje uruchamianie od 12.01.2021 — resztki usunąć.
  5. Higiena systemowa: ASR/EDR polityki block browser child, blokada wykonywania w %TEMP%.
  6. Post‑incident: przegląd polityk web (bloki *.swf), inwentaryzacja legacy.

Przykłady z kampanii / case studies

  • Watering‑hole na firmę lotniczą (lipiec 2015): strona ofiary serwowała exploit na CVE‑2015‑5122; po eksploatacji instalowano backdoor IsSpace.
  • Exploit‑kity (2015): 0‑day z wycieku Hacking Team trafił błyskawicznie do Angler/Neutrino/RIG/Magnitude (malvertising, przekierowania).
  • Reakcje vendorów: aktualizacja Adobe APSB15‑18 (18.0.0.209); Mozilla czasowo blokowała starsze wersje; CISA dodała CVE‑2015‑5122 do KEV.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w odseparowanym labie. Nie używamy prawdziwych exploitów. Celem jest walidacja detekcji łańcucha browser → child → network.

A. Szybki test detekcji (Windows)

  1. Otwórz przeglądarkę (np. Edge/Chrome), zostaw aktywne okno.
  2. W drugim oknie PowerShell uruchom „symulację dziecka” (bez złośliwości):
Start-Process -FilePath "powershell.exe" -ArgumentList "-NoLogo -NoProfile -Command whoami" -WindowStyle Hidden
Start-Process -FilePath "rundll32.exe" -ArgumentList "shell32.dll,Control_RunDLL" -WindowStyle Hidden

Ten test nie odtworzy rodzica=browser, ale pozwala przetestować parsowanie pól i konfigurację korelacji w SIEM/EDR (warunki z sekcji 7). Następnie tymczasowo wyświetl alerty „wszędzie”, aby potwierdzić, że reguły działają i dociśnij tuning do parent=browser.

B. Atomic Red Team — technika pokrewna (User Execution)
Zainstaluj Invoke-AtomicRedTeam i wykonaj bezpieczne atomiki dla T1204 (np. testy link/pliku nie ściągające malware) — cel: zobaczyć eventy procesowe i dopracować korelacje.

Set-ExecutionPolicy Bypass -Scope Process -Force
iwr https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install.ps1 | iex
Invoke-AtomicTest T1204.002 -ShowDetails -PromptForInputArgs

Dokumentacja i repozytoria: Atomic Red Team, Invoke-AtomicRedTeam.

C. Higiena legacy — skan resztek Flash
Sprawdź, czy na hostach nie ma katalogów C:\Windows\SysWOW64\Macromed\Flash\ lub starych OCX/DLL i usuń/wycofaj — Flash jest EOL i blokowany.


Mapowania (Mitigations, powiązane techniki)

Mitigations (MITRE):

  • M1051 — Update Software (patch management przeglądarek/wtyczek; historycznie APSB15‑18).
  • M1040 — Behavior Prevention on Endpoint (ASR/EDR: blok browser‑child).
  • M1031 — Network Intrusion Prevention (IDS/IPS/secure web gateway; blokowanie *.swf, wykrywanie przekierowań/ek).
  • M1017 — User Training (świadomość soc‑eng/malvertising).

Powiązane techniki ATT&CK:

  • T1189 Drive‑by Compromise (malvertising, iFrame, redirect).
  • T1204.001/002 User Execution: Malicious Link/File.
  • T1105 Ingress Tool Transfer (pobranie ładunku po eksploatacji). (strona referencyjna ogólna)

Źródła / dalsza literatura

  1. NVD — opis CVE‑2015‑5122 (CWE‑416, zakres wersji, CVSS, „exploited in the wild”). (NVD)
  2. CERT/CC VU#338736 — opaqueBackground UAF, APSB15‑18, wersja naprawcza 18.0.0.209. (kb.cert.org)
  3. CISA KEV — wpis dla CVE‑2015‑5122. (NVD)
  4. MITRE ATT&CK T1203 / T1189 / T1204.* (opisy technik i detekcje). (MITRE ATT&CK)
  5. Palo Alto Networks Unit 42 — watering‑hole na aerospace z wykorzystaniem CVE‑2015‑5122. (Unit 42)
  6. Malwarebytes (J. Segura) — EK (Angler/RIG/Neutrino/Magnitude) przyjmują 0‑day Flash. (Malwarebytes)
  7. Keysight/analiza Angler EK — techniki przekierowań (302 cushioning, domain shadowing). (Keysight)
  8. Adobe — EOL/blokada Flash od 12.01.2021. (Adobe)
  9. Mozilla — blokowanie starych wersji Flash (soft‑block). (Mozilla Support)
  10. Trend Micro — podsumowanie EK w 2015 r. (dominacja Flash, malvertising). (www.trendmicro.com)
  11. ATT&CK v18 — info o wersji/aktualizacjach. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Reguły z sekcji 7 wdrożone (Sigma/SPL/KQL/EQL) + korelacja proxy/DNS ±2 min.
  • Alarm „browser → child (interpreter/LOLBin)” = high + auto‑contain host.
  • Widoczność na WER/crashe pluginów i file drops w %TEMP%.
  • Blokowanie *.swf i legacy MIME w web‑gateway/NGFW.
  • Threat hunt: hosty z pepflashplayer.dll / NPSWF*.dll.

CISO (strategiczne):

  • Politycznie zabroniony Flash (potwierdzona deinstalacja; EOL).
  • ASR/EDR: „Block Office/Browser child process” i „Block executable content from email/web.”
  • Patch management (M1051) — gwarancja aktualnych przeglądarek; legacy wycofane.
  • Program szkoleń użytkowników (malvertising, „click‑to‑play” historia).

Uwagi końcowe

Flash Player jest wyłączony i blokowany przez Adobe — jakiekolwiek pozostałości należy usuwać. Dzisiejsza wartość detekcyjna polega na rozpoznawaniu wzorca zachowań klient‑strona, który pozostaje aktualny dla nowych błędów RCE w przeglądarkach/wtyczkach.