Archiwa: APT - Strona 24 z 31 - Security Bez Tabu

CISA nakazuje załatomanie zero-day Samsunga (CVE-2025-21042) wykorzystywanego do ataków spyware „LandFall”


Wprowadzenie do problemu / definicja luki

Amerykańska CISA dołączyła do katalogu Known Exploited Vulnerabilities (KEV) krytyczną lukę w urządzeniach Samsung Galaxy – CVE-2025-21042 – i nakazała agencjom federalnym natychmiastowe załatanie floty. Błąd to out-of-bounds write w bibliotece libimagecodec.quram.so, który umożliwia zdalne wykonanie kodu (RCE) na urządzeniach z Androidem 13+ po przetworzeniu specjalnie spreparowanego obrazu. Samsung załatał problem w SMR Apr-2025 Release 1. CISA ustaliła termin naprawy na 1 grudnia 2025 r. w ramach BOD 22-01.

Równolegle zespół Unit 42 opisał kampanię szpiegowską LANDFALL, która wykorzystywała tę lukę poprzez obrazy DNG dostarczane m.in. przez WhatsApp.


W skrócie

  • CVE-2025-21042: błąd zapisu poza buforem w libimagecodec.quram.soRCE po otwarciu/przetworzeniu obrazu (DNG). Łatka: SMR Apr-2025 Release 1.
  • Wykorzystanie w atakach: spyware LANDFALL, dostarczany w zmodyfikowanych plikach DNG (obraz + dołączone archiwum ZIP z komponentami .so).
  • Status CISA: wpis w KEV z datą dodania 10 listopada 2025 i terminem 1 grudnia 2025 na wdrożenie mitigacji/aktualizacji.
  • Zasięg: modele flagowe Galaxy (m.in. S22/S23/S24, Z Fold4/Z Flip4); potencjalne ofiary w Iraku, Iranie, Turcji, Maroku.

Kontekst / historia / powiązania

Unit 42 wskazuje, że próbki złośliwych obrazów DNG pojawiały się w VirusTotal od lipca 2024 r., a kampania trwała miesiącami przed publikacją poprawki w kwietniu 2025 r. Luka została prywatnie zgłoszona do Samsunga jesienią 2024 r., a numer CVE nadano w 2025 r.

CISA ujęła CVE-2025-21042 w KEV i publicznie zaapelowała o szybkie działania naprawcze – zgodnie z praktyką, gdy luka jest aktywnie wykorzystywana. NVD potwierdza krytyczną ocenę (CVSS v3.1 do 9.8 wg NVD) i odniesienia do KEV oraz biuletynu Samsunga.

W tym samym komponencie (libimagecodec.quram.so) Samsung łatał też CVE-2025-21043 we wrześniu 2025 r., również wcześniej obserwowaną „in the wild”. To sugeruje szerszy trend nadużywania parserów RAW/DNG na platformach mobilnych.


Analiza techniczna / szczegóły luki

Wektor wejścia
Atakujący wysyła spreparowany plik DNG (Digital Negative). Podczas parsowania obrazu przez libimagecodec.quram.so dochodzi do zapisu poza buforem i przejęcia przepływu sterowania. W próbkach LANDFALL na końcu DNG dołączono ZIP z komponentami ELF (b.so – loader/backdoor oraz moduł manipulujący politykami SELinux), które po eksploatacji są wyodrębniane i wykonywane.

Warstwa exploita

  • Błąd został naprawiony w SMR Apr-2025 R1 (Samsung Mobile Release).
  • W ocenie NVD: RCE zdalne, często przy minimalnej interakcji użytkownika (w niektórych ścieżkach wystarczy automatyczne przetworzenie miniatury/metadata).

Łańcuch infekcji LANDFALL (skrót)

  1. Dostarczenie obrazu DNG przez komunikator (np. WhatsApp).
  2. Parsowanie → wyzwolenie OOB write w libimagecodec.quram.so.
  3. Rozpakowanie dołączonego ZIP i uruchomienie b.so.
  4. Manipulacja SELinux dla uprawnień/persistencji; telemetryka i exfiltracja (kontakty, SMS, lokalizacja, audio, zdjęcia, logi połączeń).

Praktyczne konsekwencje / ryzyko

  • Zero-click/low-click: w zależności od ścieżki przetwarzania mediów na urządzeniu/wersji aplikacji, exploit może wymagać minimalnej lub zerowej interakcji. Ryzyko dotyczy też miniatur/preview.
  • Zasięg urządzeń: liczne generacje Galaxy na Androidzie 13+; floty BYOD/COPE w organizacjach mogą być podatne do czasu aktualizacji.
  • Skutki incydentu: pełna inwigilacja (mikrofon, geolokacja, pliki), utrata poufności danych służbowych, możliwość wtórnego ruchu C2 i eskalacji.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe łatanie (priorytet 1)

  • W MDM/EMM wymuś aktualizację do SMR Apr-2025 R1 lub nowszej (docelowo najnowszy SMR dostępny dla danego modelu). Egzekwuj regułę „block non-compliant” dla urządzeń bez poprawki.

2) Twarde zasady dla mediów w komunikatorach (tymczasowe)

  • Do czasu pełnego rollout’u rozważ wyłączenie auto-pobierania mediów w zarządzanych komunikatorach albo polityki „open-in-viewer sandbox” (jeśli MDM/Knox to wspiera). (Ogólna praktyka ograniczająca powierzchnię ataku obrazami RAW.)

3) Telemetria i hunting

  • Monitoruj katalogi mediów komunikatorów pod kątem pliki .dng / JPEG zawierające podpis ZIP na końcu (magic 50 4B 03 04).
    Przykładowy one-liner dla urządzeń z dostępem ADB (urządzenia testowe/lab):
# Szukaj artefaktów plików DNG/JPEG z dołączonym ZIP w MediaStore WhatsAppa
adb shell 'for f in $(find /sdcard/WhatsApp/Media -type f \( -iname "*.dng" -o -iname "*.jpg" -o -iname "*.jpeg" \) 2>/dev/null); do \
  tail -c +1 "$f" | hexdump -Cv | tail -n +1 | grep -q "50 4b 03 04" && echo "[SUSPECT] $f"; done'
  • Przejrzyj ruch pod kątem anomalii do domen/IP C2 (jeśli posiadasz IOK/IOC z Twoich sensorów lub z raportów komercyjnych). Unit 42 wskazuje obszary geograficzne i podobieństwa infrastrukturalne do komercyjnych PSSA/PSOA, ale nie publikuje jednoznacznej atrybucji.

4) Kontrola uprawnień i detekcja zachowań

  • Upewnij się, że agent MTD/Mobile EDR ma zasady wykrywania nietypowych uprawnień SELinux i prób wywołań loaderów .so z katalogów danych aplikacji.
  • W SIEM utwórz reguły korelacyjne na: nagłe uruchomienia mikrofonu w tle + transfer danych + aktywność lokalizacyjna na urządzeniach Galaxy.

5) Reagowanie na incydent (IR)

  • Izoluj urządzenie (Knox/MDM: tryb „lost mode”/block network), wykonaj cold reboot, zbierz ADB bugreport i kopię katalogów mediów do analizy.
  • Jeśli wykryto wskaźniki LANDFALL: factory reset + odtworzenie z czystej kopii, rotacja kont/kluczy używanych na urządzeniu.

6) Polityki długofalowe

  • W standardach bezpieczeństwa mobilnego dodaj wymóg: „aktualizacje SMR ≤30 dni” oraz „parsery obrazów RAW/DNG pod specjalnym nadzorem” (testy regresji).
  • Minimalizuj zaufanie do bibliotek multimedialnych – sandboxy, ograniczenia parserów w aplikacjach o podwyższonym zaufaniu.

Różnice / porównania z innymi przypadkami

  • CVE-2025-21042 vs CVE-2025-21043 (Samsung, ten sam komponent)
    Obie luki dotyczą libimagecodec.quram.so i formatu DNG, lecz 21042 (załatana w kwietniu 2025) jest bezpośrednio powiązana z kampanią LANDFALL. 21043 (załatana we wrześniu 2025) również była obserwowana „in the wild”, ale nie w tej konkretnej kampanii. Dla SOC/MDM praktycznie oznacza to patch oba zestawy SMR i objęcie parsera DNG testami bezpieczeństwa.
  • Paralela do ekosystemu Apple/WhatsApp (2025 r.)
    Unit 42 wskazuje podobieństwa do równoległych łańcuchów na iOS (m.in. CVE-2025-43300 po stronie DNG i CVE-2025-55177 po stronie WhatsApp); nie ma jednak dowodu na nieznaną lukę w samym WhatsApp w scenariuszu Samsung/Android. Wniosek: parsery obrazów RAW stały się istotnym wektorem APT/spyware w 2024–2025.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj wszystkie Galaxy do SMR Apr-2025 R1 lub nowszej – to eliminuje CVE-2025-21042, którą CISA klasyfikuje jako aktywnie wykorzystywaną (KEV, termin 1.12.2025 dla FCEB).
  • Wprowadź tymczasowe ograniczenia dla mediów DNG w komunikatorach do czasu 100% zgodności floty.
  • Usprawnij hunting pod kątem anomalii w obrazach (DNG z dołączonym ZIP) i zachowań (SELinux, mikrofon, exfil).
  • Traktuj parsery grafiki jako powierzchnię wysokiego ryzyka – regularne testy i szybkie rollouty SMR.

Źródła / bibliografia

  1. NVD – CVE-2025-21042: opis, CVSS, odniesienia do KEV i SMR Apr-2025 R1. (NVD)
  2. Samsung Mobile Security – SMR Apr-2025 R1: biuletyn z poprawką dla libimagecodec.quram.so. (Samsung Mobile Security)
  3. Unit 42 (Palo Alto Networks) – LANDFALL: pełna analiza kampanii, wektor DNG, komponenty .so, oś czasu i kraje celów. (Unit 42)
  4. CISA KEV/BOD 22-01 (poprzez NVD): data dodania do KEV (2025-11-10), termin naprawy (2025-12-01) i wymóg zastosowania mitigacji. (NVD)
  5. NVD – powiązania i historia zmian: wpisy dot. KEV i referencji Unit 42/Samsung. (NVD)

Groźne luki w runC umożliwiają ucieczkę z kontenerów Dockera i Kubernetesa (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881)

Wprowadzenie do problemu / definicja luki

Na początku listopada 2025 r. ujawniono trzy poważne podatności w runC – referencyjnej implementacji OCI wykorzystywanej m.in. przez Dockera, containerd i CRI-O. Każda z nich może prowadzić do pełnego przełamania izolacji kontenera i uzyskania dostępu do systemu-gospodarza (hosta) z uprawnieniami roota, głównie poprzez wymuszenie niebezpiecznych zapisów do plików w procfs. Łatki opublikowano w wersjach runC 1.2.8, 1.3.3 oraz 1.4.0-rc.3 i nowszych.


W skrócie

  • Trzy CVE: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881.
  • Wspólny efekt: możliwość skierowania zapisu wykonywanego przez runC do „wrażliwych” plików w /proc (np. .../proc/sysrq-trigger), co otwiera drogę do eskalacji i ucieczki z kontenera.
  • Zakres: dotyczy praktycznie wszystkich linii runC stosowanych pod Linuksem (szczegóły wersji poniżej).
  • Status: dostępne aktualizacje; dystrybutorzy i chmury publikują obrazy z łatami (Ubuntu, Red Hat, Google COS, AWS EKS).

Kontekst / historia / powiązania

Zespół runC poinformował społeczność (kanały oss-security) o trzech podatnościach wysokiej wagi. W ciągu tego samego dnia wydano poprawione wydania (1.2.8/1.3.3/1.4.0-rc.3). Producenci dystrybucji Linuksa i dostawcy chmur zaczęli sukcesywnie wypychać aktualizacje obrazów node’ów Kubernetes i paczek systemowych.


Analiza techniczna / szczegóły luki

1) CVE-2025-31133 — nadużycie maskedPaths z /dev/null (maskowanie za pomocą bind-mount)

  • Mechanizm: runC maskuje wrażliwe ścieżki bind-mountem /dev/null nad docelowym plikiem.
  • Luka: jeśli atakujący podmieni /dev/null na dowiązanie symboliczne wskazujące na plik pod /proc, runC nie weryfikuje dostatecznie źródła i zamountuje cel symlinku RW – przez co uzyskuje się zapis do zabronionych plików procfs.
  • Zasięg: dotyczy wszystkich znanych wersji runC przed poprawką.

2) CVE-2025-52565 — błąd w bind-mouncie /dev/console

  • Mechanizm: podczas tworzenia /dev/console runC bind-montuje odpowiedni /dev/pts/$n do wnętrza kontenera.
  • Luka: wyścig i brak poprawnych sprawdzeń pozwalają na podmianę /dev/pts/$n na symlink — runC zamountuje wtedy nieoczekiwany cel nad /dev/console, zanim zostaną nałożone maskedPaths/readonlyPaths, otwierając furtkę do RW na krytycznych plikach.
  • Zasięg: od 1.0.0-rc3 w górę, obejmuje szerokie spektrum wydań.

3) CVE-2025-52881procfs write redirect i „gadżety zapisu” (arbitrary write)

  • Mechanizm: przy sprzyjających warunkach (m.in. wyścigi na współdzielonych montach), runC można nakłonić do przekierowania własnych zapisów do /proc na inne cele w procfs, de facto uzyskując dowolny zapis do niebezpiecznych plików.
  • Skutek uboczny: omijanie LSM re-labeling (np. AppArmor/SELinux) znane z wcześniejszych prac — ułatwia łańcuchowanie z 31133.
  • Zasięg: szeroki (dotyka wspieranych linii przed aktualizacją).

Wersje naprawione

  • runC 1.2.8, 1.3.3 i 1.4.0-rc.3 (i nowsze) zawierają łatki na wszystkie trzy CVE. Jeżeli korzystasz z Dockera/containerd/CRI-O, to po stronie hosta liczy się wersja binarki runC dostarczana przez system albo obraz node’a.

Praktyczne konsekwencje / ryzyko

  • Ucieczka z kontenera: możliwość nadpisania/zapisania do kluczowych wpisów procfs (/proc/sysrq-trigger, /proc/self/attr/..., itp.) umożliwia m.in. reset systemu, manipulacje bezpieczeństwem jądra czy obejście etykiet LSM — finalnie root na hoście.
  • Łańcuchowanie: 52881 może neutralizować warstwę LSM, co zwiększa skuteczność 31133.
  • Wejście w wektor przez pipeline’y buildowe: podatności da się wyzwalać podczas buildów (np. docker buildx) i przy niestandardowych konfiguracjach montowań — realne ryzyko dla CI/CD.
  • Brak exploitów 0-day w obiegu w momencie publikacji, ale wymagany jest natychmiastowy patch – powierzchnia ataku jest powszechna (runC jest „wszędzie”).

Rekomendacje operacyjne / co zrobić teraz

0. Szybka walidacja środowiska

Sprawdź, jaką wersję runC faktycznie uruchamia host/worker:

# na hoście
runc --version

# jeśli runc dostarcza dystrybucja:
dpkg -l | grep -E 'runc'            # Debian/Ubuntu
rpm -q runc                         # RHEL/CentOS/Fedora/SUSE

# containerd
ctr version | grep -i runc
crictl info | jq '.config.containerd.runtimes'

# Kubernetes node (przez SSH na worker)
kubelet --version

1. Aktualizacje (preferowane)

  • System/obrazy node’ów: zaktualizuj paczki runc/containerd lub przeprowizjonuj AMIs/OS images dla klastrów (EKS/AKS/GKE/COS ma już rollout z łatą).
  • Minimalne bezpieczne wersje runC: 1.2.8 / 1.3.3 / 1.4.0-rc.3 (lub nowsze).
  • Przykładowe ścieżki:
    • Ubuntu: sudo apt-get update && sudo apt-get install --only-upgrade runc (USN-7851-1).
    • RHEL/SUSE: sudo dnf update runc / zypper up runc (RHSA/SUSE advisory).
    • EKS: zaktualizuj node groups / wymuś rolling replace zgodnie z biuletynem AWS.
    • Google COS/GKE: dobierz najnowszy cos-stable z notatek wydania.

2. Dodatkowe twardnienie (gdy patch jeszcze w toku)

Poniższe nie zastępują aktualizacji, ale ograniczają ryzyko:

  • User Namespaces (bez mapowania hostowego UID 0): uruchamiaj kontenery z root-less lub z remapowaniem UID/GID – uniemożliwia wielu ścieżkom zapisu do procfs dzięki DAC.
  • Rootless Docker/Podman tam, gdzie to możliwe.
  • Ogranicz niestandardowe montowania w docker run, PodSpec i pipeline’ach buildowych (buildx) – polityki Admission Controller (OPA/Gatekeeper/Kyverno) blokujące hostPath, --mount, nieautoryzowane bind-mounty, SYS_ADMIN, CAP_SYS_ADMIN.
  • LSM / seccomp / AppArmor/SELinux: włączone profile to wciąż bariera, choć 52881 redukuje ich skuteczność – traktuj to jako warstwę „Defense in Depth”.
  • ReadOnlyRootFilesystem, no-new-privileges, drop większości capabilities; brak --privileged.
  • RBAC: zablokuj możliwość tworzenia podów z niestandardowymi montami przez nieuprawnionych deweloperów.

3. Wykrywanie i obserwowalność

  • Sygnatury EDR/eBPF/Falco pod kątem:
    • Podejrzanych symlinków w /dev/pts/* i podmian /dev/null podczas init kontenera.
    • Zapisów do plików /proc/ nietypowych dla workloadu (np. */proc/sysrq-trigger, */proc/*/attr/*).
  • Telemetria z auditd/BPF i korelacja z cyklem życia kontenerów. (Sysdig publikuje wskazówki detekcyjne oraz opis wektorów).

Przykładowa reguła Falco (szkic – dostosuj do środowiska):

- rule: Suspicious_Procfs_Write_From_Container
  desc: "Zapis do krytycznych plików procfs przez proces w kontenerze"
  condition: evt.type in (open,openat) and fd.name pmatch (
               "/proc/sysrq-trigger",
               "/proc/*/attr/*",
               "/proc/sys/kernel/*"
             ) and container and (evt.arg.flags & O_WRONLY != 0 or evt.arg.flags & O_RDWR != 0)
  output: "procfs write in container (user=%user.name proc=%proc.name file=%fd.name container=%container.id)"
  priority: CRITICAL
  tags: [container, mitre-privilege-escalation]

Różnice / porównania z innymi przypadkami

  • Historyczne analogie: 52881 to „bardziej wyrafinowany” następca problemów z LSM relabel obserwowanych wcześniej (np. CVE-2019-19921). Wspólny motyw to przekierowanie zapisów wykonywanych przez sam runtime, co omija klasyczne sandboxowe ograniczenia procesu w kontenerze.
  • Wobec CVE w Docker Desktop 2025 (SSRF/ECI): inna klasa – tam problem dotyczył środowiska desktop/WSL2 i API dockerd, tutaj mówimy o jądrze i procfs w runtime. (Wspólna nauka: aktualizacje toolchainu kontenerowego są krytyczne).

Podsumowanie / kluczowe wnioski

  • Te trzy CVE w runC to fundamentalne problemy izolacji kontenera; aktualizacja runC do 1.2.8/1.3.3/1.4.0-rc.3 (lub nowszej) powinna być traktowana jak pilny changerequest na wszystkich hostach/workerach.
  • Do czasu pełnego patcha: rootless/userns, blokady niestandardowych montów i wzmocnione monitorowanie procfs.
  • Zadbaj o pipeline’y buildowe (buildx) i obrazy bazowe node’ów w chmurach – wielu dostawców już publikuje zaktualizowane obrazy, ale rollout bywa rozłożony w czasie.

Źródła / bibliografia

  • BleepingComputer: przegląd i wersje naprawione (1.2.8/1.3.3/1.4.0-rc.3). (BleepingComputer)
  • GitHub (opencontainers/runc) – release notes z opisem trzech CVE i kontekstem technicznym. (GitHub)
  • NVD: karty CVE z opisem zakresu wersji i szczegółami (31133, 52565, 52881). (NVD)
  • Advisory/dystrybutorzy: Ubuntu USN-7851-1; Red Hat RHSA-2025:19927; Google COS release notes; AWS Security Bulletin (EKS). (Ubuntu)
  • Sysdig: analiza wektorów i wskazówki detekcyjne. (sysdig.com)

N. Korea–backed hackers kasują dane i rozprzestrzeniają malware przez KakaoTalk. Nowa taktyka zdalnego resetu urządzeń

Wprowadzenie do problemu / definicja luki

Według najnowszych doniesień południokoreańskich mediów i analizy Genians Security Center (GSC), aktor powiązany z Koreą Północną prowadzi kampanię, w której przejmuje konta ofiar (Google i lokalne serwisy), dostarcza malware przez komunikator KakaoTalk (w tym wersję PC), a następnie zdalnie resetuje urządzenia mobilne (Android) i usuwa kluczowe dane (zdjęcia, dokumenty, kontakty). Co więcej, zainfekowane komputery i tablety wykorzystywane są do dalszej dystrybucji złośliwych plików do kontaktów ofiary, a w części przypadków napastnicy wykorzystywali kamerę internetową do potwierdzania nieobecności właściciela.


W skrócie

  • Wejście odbywa się przez fałszywe “programy odstresowujące” dystrybuowane przez KakaoTalk; pakiet to MSI z podpisem cyfrowym (nadużycie legalnego certyfikatu wydanego chińskiemu podmiotowi), w środku skrypty AutoIt i dodatkowe komponenty.
  • Po kradzieży sesji/kont napastnik uruchamia zdalny reset/factory reset Androida (z poziomu usług Google), czasem wielokrotnie, aby utrudnić odzyskanie. Dane na telefonie znikają.
  • Z przejętej sesji KakaoTalk (PC) atakujący rozesyła malware do znajomych ofiary, poszerzając zasięg.
  • Źródła medialne łączą kampanię z klastrami Kimsuky lub APT37 (Reaper) – taktyka wskazuje na dojrzałe APT ukierunkowane na inwigilację i destrukcję danych.
  • W tym samym okresie raportowano nowe narzędzia Kimsuky (np. backdoor “HttpTroy”), co potwierdza intensywną ewolucję arsenału DPRK.

Kontekst / historia / powiązania

Klastry Kimsuky/Thallium i APT37/Reaper od lat realizują kampanie szpiegowskie i wpływają na ekosystem bezpieczeństwa w Korei i poza nią: spear-phishing, LNK/CHM/HWP, AutoIt, oraz nadużycia chmurowych C2 (Dropbox, Yandex, Gmail). Dorobek doradczy CISA dla DPRK cyber actors podkreśla ich zdolność do kradzieży danych, utrzymywania długotrwałej obecności i ciągłej mutacji TTP. Nowy wątek – skoordynowana “neutralizacja” urządzeń ofiar (factory reset) – to jakościowy skok w modelu operacyjnym.


Analiza techniczna / szczegóły luki

Wejście i pierwsze etapy

  1. Initial Access – malspam / IM delivery
    Ofiary otrzymują w KakaoTalk link/załącznik do archiwum ZIP zawierającego MSI “Stress Clear.msi”. MSI posiada ważny podpis cyfrowy (nadużycie zaufania), a w środku komponenty uruchamiające AutoIt i ładunki pomocnicze.
  2. Execution & Defense Evasion
    Skrypty AutoIt dekompresują/ładowują moduły, wykorzystują nazewnictwo katalogów sugerujące “broń ataku” (ang. Attack Weapon) i wykonują kroki ukrywania (np. anty-EDR, living-off-the-land).
  3. Credential Access & Session Hijack
    Po zainfekowaniu kradzione są dane kont: Google i lokalnych usług (przeglądarki, tokeny, ciasteczka), co umożliwia zdalne akcje na urządzeniach.

Eskalacja: zdalny reset i destrukcja danych na Androidzie

  • Napastnik korzysta z mechanizmów Google do zdalnego zarządzania urządzeniem (po zalogowaniu na skompromitowane konto) i uruchamia factory reset/remote wipe. W wielu incydentach komenda była wykonywana wielokrotnie (≥3x), by utrudnić odzyskanie.
  • Zanim dojdzie do resetu, operator potrafi sprawdzić lokalizację urządzenia i/lub poprzez kamerę laptopa upewnić się, że ofiara jest poza domem/biurem – minimalizuje to ryzyko szybkiej reakcji.

Lateral/social propagation z poziomu PC

  • Po resetach telefonów atakujący używa KakaoTalk (PC) na już zalogowanym komputerze ofiary, aby rozsyłać kolejne paczki malware do kontaktów (tzw. account-based propagation). To opóźnia wykrycie – ofiara traci powiadomienia na telefonie.

Nowe narzędzia w ekosystemie DPRK

  • Równolegle obserwujemy nowe backdoory (np. HttpTroy w kampanii Kimsuky), co potwierdza ciągłe R&D po stronie aktorów DPRK i łatwe rotowanie TTP/implantów.

Praktyczne konsekwencje / ryzyko

  • Utrata danych użytkownika: trwałe skasowanie zdjęć, dokumentów, kontaktów na urządzeniu mobilnym (brak backupu = nieodwracalne straty).
  • Supply-chain społeczny: przejęte kontakty w KakaoTalk stają się kanałem do infekcji łańcuchowej w organizacjach (BYOD/COPE).
  • Utrata widoczności i opóźnienie wykrycia: brak powiadomień na zresetowanym telefonie de facto odcina kanały 2FA/alertów, zmniejsza szanse szybkiej reakcji.
  • Ryzyko nadzoru fizycznego: użycie kamery/lokalizacji do świadomego timingu ataku (gdy użytkownik jest offline).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SOC/Blue Team

Detekcje (EDR/SIEM/Sysmon)

  • Wykrywaj uruchomienia msiexec.exe z nietypowymi ścieżkami/parametrami (z katalogów użytkownika / %TEMP%).
  • Poluj na AutoIt: procesy AutoIt3.exe / skrypty .au3 / sekcje PE z ciągami “AutoIt”.
  • Monitoruj przeglądarkowe tokeny/sesje: nienaturalne logowania do Google (nowe urządzenia, niespotykane ASN/geo) zsynchronizowane z resetami urządzeń.

Przykładowa reguła Sigma (Windows – MSI z %TEMP%)

title: Suspicious MSI Install from Temp
id: 7b1a7e8a-7d1f-4d3e-9a0b-apt-kr-msi
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\msiexec.exe'
    CommandLine|contains:
      - '\AppData\Local\Temp\'
      - '\Downloads\'
  condition: selection
level: high
tags: [attack.execution, t1059, t1204]

Przykładowa reguła Sigma (AutoIt)

title: AutoIt Interpreter Execution
id: 9d3af2d2-0f1a-41a6-9af0-autoit
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  sel1:
    Image|endswith:
      - '\AutoIt3.exe'
      - '\AutoIt3_x64.exe'
  sel2:
    CommandLine|contains:
      - '.au3'
  condition: sel1 or sel2
level: medium
tags: [attack.execution, t1059]

Hunting – przykładowe kwerendy (Sysmon/EDR)

  • Nietypowe połączenia wychodzące tuż po uruchomieniu msiexec.exe/AutoIt3.exe.
  • Zmiany w katalogach przeglądarek (Login Data, Cookies) korelowane z nowymi logowaniami na konto Google.
  • Wzorzec: reset Androida (zdarzenie bezpieczeństwa konta) + aktywność KakaoTalk (PC) wysyłająca pliki do wielu kontaktów.

Dla administratorów IT / SecOps

  1. Konta i MDM
    • Wymuś MFA (najlepiej klucze FIDO2) na kontach Google służbowych.
    • Alerting na “Find My Device / Remote wipe” — w Google Workspace skonfiguruj reguły zdarzeń konta i powiadomienia bezpieczeństwa.
    • Zarządzaj Androidem przez MDM/Workspace: polityka blokady factory reset bez zgody IT; wymuś szyfrowanie i automatyczne kopie w chmurze.
  2. Aplikacje i poczta/IM
    • Ogranicz załączniki i EXE/MSI w komunikatorach desktopowych (DLP/antimalware na warstwie proxy/endpoint).
    • Application Control: zabroń msiexec.exe dla zwykłych użytkowników, zezwalaj tylko z podpisami znanych wydawców (wszędzie, gdzie to możliwe – allow-list).
    • Dezaktywuj autologowanie KakaoTalk (PC) i wymuszaj blokadę ekranu.
  3. Twarde higiena kont
    • Przeglądy sesji Google (Security Checkup): wylogowanie ze wszystkich urządzeń, rotacja haseł, przegląd autoryzowanych aplikacji OAuth.
    • Geofence/Impossible Travel: blokuj dziwne logowania; rozważ risk-based access.
  4. Reakcja na incydent (IR) – playbook skrócony
    • Odłącz zainfekowany PC od sieci → wyloguj sesje kont (Google/Kakao) → przymusowa zmiana haseł + unieważnienie tokenów OAuth.
    • Android: jeśli już zresetowany, traktuj jak utracony – przywracaj z weryfikowanego backupu, nie przywracaj niezaufanych APK/konfiguracji.
    • Powiadom kontakty (zwłaszcza niefirmowe), że nie wolno otwierać przesłanych plików z poprzedniej konwersacji.
  5. Szkolenia użytkowników
    • Programy antystresowe”, “aktualizacje-szybkie naprawy” przez komunikatory = czerwona flaga.
    • Weryfikuj: nawet jeśli nadawcą jest ktoś znany – mogło dojść do przejęcia sesji.

Dla użytkowników końcowych (BYOD/COPE)

  • Kopia zapasowa (Zdjęcia/Drive/Signal/WhatsApp) w harmonogramie.
  • Blokada konta Google: włącz alerty bezpieczeństwa, autoryzację logowania na zaufanych urządzeniach.
  • Nie instaluj MSI/EXE z czatu; używaj sklepu i oficjalnych stron.

Różnice / porównania z innymi przypadkami

  • Klasyczne kampanie Kimsuky/APT37 koncentrowały się na exfiltracji (LNK, HWP, RoKRAT, spear-phishing) i utrzymaniu dostępu. Tu obserwujemy połączenie exfiltracji z celowym “neutralizowaniem” urządzeń mobilnych przez zdalny reset, co opóźnia detekcję i ułatwia propagację z konta komunikatora. To mniej typowe w porównaniu z wcześniejszymi, czysto szpiegowskimi operacjami.

Podsumowanie / kluczowe wnioski

  • Kampania przypisywana klastrom Kimsuky/APT37 łączy socjotechnikę, MSI + AutoIt, kradzież sesji i zdalny reset Androida, by jednocześnie zniszczyć dane i rozszerzyć infekcję przez KakaoTalk (PC). To eskalacja TTP DPRK w kierunku szybkiego paraliżu komunikacyjnego ofiary.
  • Organizacje powinny wzmocnić kontrolę nad MSI/AutoIt, zabezpieczyć konta Google (MFA FIDO2), wdrożyć MDM z politykami anti-reset i agresywnie monitorować zdarzenia kont powiązane z “Find My Device/Remote Wipe”.

Źródła / bibliografia

  1. The Korea Times – “N. Korea-backed hackers deploy new malware-led cyberattack: report” (Nov 10, 2025). (The Korea Times)
  2. Genians Security Center – “State-Sponsored Remote Wipe Tactics Targeting Android …” (analiza techniczna MSI/AutoIt, reset urządzeń, propagation via KakaoTalk PC). (genians.co.kr)
  3. The Chosun Biz (EN) – “North Korean hackers wipe Korean devices by remotely resetting phones and PCs …” (kontekst medialny i zasięg). (Chosunbiz)
  4. The Hacker News – “New HttpTroy Backdoor … (Kimsuky)” (ewolucja narzędzi DPRK). (The Hacker News)
  5. CISA – “North Korea State-Sponsored Cyber Threat: Publications/Advisories” (tło i profil TTP DPRK). (cisa.gov)

China-linked APT na celowniku: długotrwała kampania szpiegowska przeciwko amerykańskiej organizacji non-profit

Wprowadzenie do problemu / definicja luki

W kwietniu 2025 r. amerykańska organizacja non-profit, zaangażowana w kształtowanie polityki międzynarodowej USA, została cicho skompromitowana przez aktora powiązanego z ChRL. Napastnicy utrzymywali dostęp przez tygodnie, budując persystencję i przygotowując się do długoterminowej kradzieży informacji. Najważniejsze: wykorzystano DLL sideloading z legalnym plikiem vetysafe.exe, a także MSBuild i harmonogram zadań do “bezplikowego” uruchamiania kodu oraz zainteresowanie kontrolerami domeny (DC), sugerujące zamiar przejęcia środowiska AD. To wpisuje się w wieloletnie wzorce chińskich operacji wywiadowczych ukierunkowanych na podmioty mające wpływ na politykę USA.

W skrócie

  • Cel: amerykańska instytucja non-profit wpływająca na politykę zagraniczną USA.
  • Czas: pierwsze ślady 5 kwietnia 2025; intensywna aktywność 16 kwietnia; utrzymanie dostępu przez tygodnie.
  • Wejście: skan masowy pod znane RCE (m.in. Log4Shell, CVE-2022-26134 w Atlassian, Apache Struts CVE-2017-9805, GoAhead RCE), następnie rekonesans i budowa persystencji.
  • TTP: scheduled task uruchamiający msbuild.exe, DLL sideloading przez vetysafe.exe → złośliwy sbamres.dll, aktywność dcsync-like; obserwacja Imjpuexc.exe (legalny komponent IME dla języków azjatyckich) na hostach.
  • Atrybucja: zbieżność TTP/artefaktów z kampaniami Kelp/Salt Typhoon (Earth Estries), Space Pirates i Earth Longzhi (sub-grupa APT41); możliwe współdzielenie narzędzi.

Kontekst / historia / powiązania

Opisane techniki i pliki łączono wcześniej z chińskimi grupami: Kelp / Salt Typhoon (Earth Estries), Space Pirates oraz Earth Longzhi (sub-grupa APT41). W 2024–2025 r. Salt Typhoon była publicznie wiązana przez FBI/CISA z serią kompromitacji operatorów telekomunikacyjnych (setki celów, dziesiątki krajów), co pokazuje skalę zdolności i apetyt wywiadowczy. Jednocześnie Trend Micro szczegółowo dokumentował długotrwałe operacje Earth Estries oraz wcześniej aktywność Earth Longzhi.

Analiza techniczna / szczegóły luki

Łańcuch ataku (kill chain)

  1. Wejście / Discovery – 5.04.2025: automatyczne skany pod publiczne RCE (Log4Shell, Atlassian OGNL, Struts, GoAhead). Celem było znalezienie “słabego punktu” ekspozycji internetowej.
  2. Rekonesans sieciowy – 16.04.2025: seria poleceń curl (również do 192.0.0.88), testy łączności i pingowanie zasobów wewnętrznych; następnie netstat do enumeracji połączeń/procesów.
  3. Persystencja i wykonanie – utworzono zadanie zaplanowane \Microsoft\Windows\Ras\Outbound, co godzinę uruchamiające msbuild.exe jako SYSTEM z plikiem outbound.xml. Z niego ładowano kod do csc.exe, który łączył się z C2: http://38.180.83[.]166/6CDF0FC26CDF0FC2.
  4. Ładowanie ładunku – o 02:50 uruchomiono niestandardowy loader (SHA-256: f52b86...cb69), który odszyfrowywał i ładował w pamięci prawdopodobny RAT.
  5. Uprzywilejowanie/AD – obserwacje aktywności DCSync-like oraz obecność Imjpuexc.exe tego samego dnia; silny nacisk na DC i rozprzestrzenianie się w domenie.

DLL sideloading przez VipreAV

Napastnicy wykorzystali legalny komponent vetysafe.exe (podpis „Sunbelt Software, Inc.”) do wstrzyknięcia sbamres.dll. Ten mechanizm wcześniej widziano u aktorów z Chin (np. Space Pirates, Earth Longzhi/APT41) oraz w połączeniu z Deed RAT / Snappy Bee, współdzielonym przez kilka grup z ekosystemu PRC (m.in. Kelp/Salt Typhoon/Earth Estries).

IOC (wybór)

  • Imjpuexc.exe – SHA-256: 51ffcff8...c4d
  • msoutbound6f7f099d...50ed9
  • sbamres.dll99a0b424...b106 (łączony także z Space Pirates)
  • mmp.exe (DCSync) – dae63db9...61e2
  • vetysafe.exee356dbd3...65af2
  • msascui.exef52b86b5...cb69
  • C2: 38.180.83[.]166/6CDF0FC26CDF0FC2
    Źródło: analiza Broadcom/Symantec

Mapowanie do MITRE ATT&CK (skrócone)

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Execution: MsBuild (T1127.001), Command & Scripting (T1059)
  • Persistence: Scheduled Task/Job (T1053.005)
  • Privilege Escalation / Defense Evasion: DLL Search Order Hijacking (T1574.001), Signed Binary Proxy Execution (T1218)
  • Credential Access: DCSync (T1003.006)
  • Discovery: Network Service Scanning (T1046), System Network Connections Discovery (T1049)
  • C2: Application Layer Protocol – HTTP (T1071.001)

Praktyczne konsekwencje / ryzyko

  • Think-tank effect: organizacje non-profit zajmujące się polityką są łakomym kąskiem — mają wrażliwe kontakty/dokumenty, ale zwykle mniejszy budżet bezpieczeństwa niż agencje rządowe.
  • AD-first kompromitacja: próby DCSync i zainteresowanie DC wskazują na dążenie do pełnej dominacji domeny i trwałej obecności.
  • Tool-sharing utrudnia atrybucję: współdzielenie łańcuchów ładowania (np. vetysafe.exe + sbamres.dll) między Kelp/Earth Estries, Space Pirates i APT41/Longzhi zmniejsza wartość pojedynczych IOC — trzeba koncentrować się na behawiorystyce i korelacjach.
  • Szerszy obraz: kampanie Salt Typhoon z 2024–2025 pokazały potencjał strategicznego podsłuchu i pivotu między sektorami (telco → polityka/public policy).

Rekomendacje operacyjne / co zrobić teraz

1) Szybka walidacja (IR triage)

EDR/SIEM – zapytania ad-hoc

  • KQL (Microsoft 365 Defender / Sentinel): wykrywanie zadań MSBuild jako SYSTEM
DeviceProcessEvents
| where FileName =~ "schtasks.exe" and ProcessCommandLine has_all ("\\Microsoft\\Windows\\Ras\\Outbound", "msbuild.exe")
or (FileName =~ "msbuild.exe" and InitiatingProcessIntegrityLevel =~ "System")
  • Sigma (Windows Process Creation) – MsBuild + DLL sideloading vipre
title: Suspicious MsBuild with Outbound XML and Vipre Sideloading
id: 1d1c0b5b-2a5b-4c2e-9d1c-apt-cn-msbuild-vipre
logsource: { category: process_creation, product: windows }
detection:
  sel1:
    Image|endswith: '\msbuild.exe'
    CommandLine|contains: 'outbound.xml'
  sel2:
    Image|endswith: '\vetysafe.exe'
  condition: sel1 or sel2
level: high
tags:
  - attack.execution.T1127.001
  - attack.defense_evasion.T1218
  • YARA (na sbamres.dll wg znanych hash):
rule SBAMRES_Suspicious_DLL
{
  meta:
    description = "Detect sbamres.dll linked in Symantec report"
    sha256_1 = "99a0b424bb3a6bbf60e972fd82c514fd971a948f9cedf3b9dc6b033117ecb106"
  condition:
    uint16(0) == 0x5A4D and sha256(0, filesize) == sha256_1
}
  • PowerShell: IOC sweep (hash + ścieżki)
$hashes = @(
"51ffcff8367b5723d62b3e3108e38fb7cbf36354e0e520e7df7c8a4f52645c4d",
"6f7f099d4c964948b0108b4e69c9e81b5fc5ff449f2fa8405950d41556850ed9",
"99a0b424bb3a6bbf60e972fd82c514fd971a948f9cedf3b9dc6b033117ecb106",
"dae63db9178c5f7fb5f982fbd89683dd82417f1672569fef2bbfef83bec961e2",
"e356dbd3bd62c19fa3ff8943fc73a4fab01a6446f989318b7da4abf48d565af2",
"f52b86b599d7168d3a41182ccd89165e0d1f2562aa7363e0718d502b7e3fcb69"
)
Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object {
    try {
      $h = Get-FileHash $_.FullName -Algorithm SHA256
      if ($hashes -contains $h.Hash) { $_.FullName }
    } catch {}
  }

(IOC pochodzą z publikacji Broadcom/Symantec).

2) Utrudnij techniki użyte w kampanii

  • Zablokuj sideloading: wdroż Application Control (WDAC/AppLocker) – zezwalaj na uruchamianie vetysafe.exe tylko z oczekiwanych katalogów i z poprawnym chain-of-trust; blokuj ładowanie niezaufanych DLL obok binariów vendorów AV.
  • Twarde zasady dla MSBuild: jeżeli niepotrzebny na stacjach/serwerach, blokuj msbuild.exe; w przeciwnym razie rejestruj i alertuj wykonywanie jako SYSTEM i z plikami .xml poza zaufanymi ścieżkami.
  • AD hardening: ogranicz DC replication permissions, monitoruj DSGetNCChanges/DCSync i nieużywane replication rights; wdroż tiering administracyjny i PAW dla kont uprzywilejowanych.
  • Egress control: blokuj ruch HTTP do 38.180.83.166 i wariantów ścieżek; wdroż proxy z inspekcją egress + DLP na ruch do nieznanych hostów.
  • Patch hygiene: ponieważ initial access mógł używać znanych RCE, włącz ataki priorytetowe (OGNL Atlassian CVE-2022-26134, Log4Shell, Struts 2017-9805, GoAhead 2017-17562) w planie poprawek oraz skany pre-/post-patch.

3) Dodatkowe zalecenia zgodne z wytycznymi rządowymi (Salt Typhoon)

  • Zgodnie z poradnikami CISA/FBI/NSA dot. Salt Typhoon: segmentacja krytycznych systemów, kontrola urządzeń brzegowych, rotacja poświadczeń, telemetry z routerów/telco, odseparowanie usług zarządzania i out-of-band management. Nawet jeśli nie jesteś telco, tradecraft przenika między sektorami.

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

  • Telco 2024–2025 vs think-tank 2025: w telco dominował cel SIGINT/komunikacje (podsłuch, CDR, dane abonentów), tutaj – influence intelligence (dokumenty, korespondencja, mapy wpływów). Jednak techniki (MSBuild, sideloading, legalne binaria, długi dwell time) są spójne.
  • APT41/Earth Longzhi: ten klan od lat używa elastycznych łańcuchów ładowania i sideloadingu do ukrycia RAT-ów. Obecne artefakty (vetysafe.exe + sbamres.dll) mają historyczne analogie.
  • Earth Estries (Kelp/Salt Typhoon): Trend Micro pokazał długofalowe, “ciche” kampanie z własnymi backdoorami i użyciem SnappyBee/Deed RAT; wnioskiem jest współdzielenie toolingu między podgrupami i trudna atrybucja.

Podsumowanie / kluczowe wnioski

  • Atak na non-profit pokazuje, że organizacje kształtujące politykę są w orbicie zainteresowań aktorów państwowych z ChRL.
  • Behawiorystyka > IOC: z racji współdzielenia narzędzi, kluczem jest korelacja TTP (MSBuild + SYSTEM + harmonogram + sideloading Vipre).
  • AD to crown jewels: każda wzmianka o DCSync/replication powinna wywoływać high-severity IR.
  • Wdrożenia application control, detekcji living-off-the-land i telemetrii egress znacząco utrudniają powtórkę.

Źródła / bibliografia

  1. Broadcom/Symantec: China-linked Actors Maintain Focus on Organizations Influencing U.S. Policy (06.11.2025) – główne źródło analizy (TTP/IOC/czas). (security.com)
  2. SecurityAffairs: omówienie incydentu i streszczenie wniosków Symantec (08.11.2025). (Security Affairs)
  3. CISA/NSA/FBI: Countering Chinese State-Sponsored Actors… (27.08.2025) – kontekst Salt Typhoon i zalecenia strategiczne. (CISA)
  4. Trend Micro: Breaking Down Earth Estries’ Persistent TTPs… (08.11.2024) – tło dot. Earth Estries/Salt Typhoon/Deed RAT. (www.trendmicro.com)
  5. Trend Micro: Hack the Real Box: APT41’s New Subgroup Earth Longzhi (09.11.2022) – tło dot. Earth Longzhi/APT41. (www.trendmicro.com)

LPI Security Essentials (Moduł 021.2) – Ocena Ryzyka Bez Mitów

Zanim zaczniesz

Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.

Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.

Czytaj dalej „LPI Security Essentials (Moduł 021.2) – Ocena Ryzyka Bez Mitów”

Chrome 142: aktualizacja bezpieczeństwa łata 5 podatności (3 „High”), w tym WebGPU (CVE-2025-12725)

Wprowadzenie do problemu / definicja luki

Google wydało poprawkę bezpieczeństwa dla Chrome 142 usuwającą 5 podatności, z czego 3 mają wagę High. Najpoważniejsza z nich to błąd zapisu poza bufor (out-of-bounds write) w WebGPU – CVE-2025-12725, potencjalnie umożliwiający zdalne wykonanie kodu (RCE). Dodatkowo naprawiono błędy „inappropriate implementation” w Views (CVE-2025-12726) i V8 (CVE-2025-12727) oraz dwie usterki średniej wagi w Omnibox (CVE-2025-12728, CVE-2025-12729). Google nie raportuje na ten moment aktywnego wykorzystania tych luk. Oficjalne wersje z łatami to m.in. 142.0.7444.134/.135 dla Windows/Mac/Linux.


W skrócie

  • Zakres: 5 luk (3×High: WebGPU, Views, V8; 2×Medium: Omnibox).
  • Warianty wersji z poprawką: Windows/Mac 142.0.7444.134/.135, Linux 142.0.7444.134; rollout etapowy.
  • Eksploatacja „in the wild”: brak potwierdzenia.
  • Ryzyko praktyczne: możliwe RCE (WebGPU, V8), korupcja pamięci/stanów UI (Views), manipulacje paskiem adresu i scenariusze phishingowe (Omnibox).
  • Dla kogo priorytet: SOC/IT z dużym udziałem przeglądarki w łańcuchu pracy (SaaS, VDI, SSO, EDR w konsoli web), środowiska z WebGPU/AI w przeglądarce oraz parkiem rozszerzeń.

Kontekst / historia / powiązania

Chrome 142 został ogłoszony jako stabilny 28 października 2025 r., a kilka dni później wydano aktualizację stricte bezpieczeństwa dla desktopów ze zredukowanymi szczegółami do czasu, aż większość użytkowników się zaktualizuje (standardowa polityka). Wpis zespołu Chromium podaje listę CVE i numery wersji kanału stabilnego.


Analiza techniczna / szczegóły luki

1) WebGPU — CVE-2025-12725 (High, OOB write → RCE)

  • Natura błędu: out-of-bounds write w implementacji WebGPU (warstwa umożliwiająca stronom dostęp do GPU). Tego typu usterki to klasyczna korupcja pamięci — zapis poza przeznaczonym obszarem może prowadzić do crasha lub dowolnego wykonania kodu przy odpowiednio spreparowanych shaderach/buforach.
  • Implikacje praktyczne: złośliwe strony/aplikacje webowe uruchamiające obciążenia GPU (np. wizualizacje 3D/AI) mogą próbować eskalować błąd do RCE w procesie renderera; potencjalnie do piaskownicy, ale łańcuchy „renderer → browser” są znane z wcześniejszych kampanii. (Implikacja na bazie typologii błędu w Chrome i modelu procesów.)

2) Views — CVE-2025-12726 (High)

  • Opis: „inappropriate implementation” w frameworku Views (warstwa UI Chrome), niebezpieczne obchodzenie się z referencjami obiektów UI → możliwość korupcji pamięci po odwiedzeniu spreparowanej strony lub poprzez rozszerzenie.

3) V8 — CVE-2025-12727 (High)

  • Opis: błąd „inappropriate implementation” w silniku V8 (JS/WebAssembly). Tego rodzaju defekty (np. type confusion, błędy pamięci) są historycznie atrakcyjne do RCE przez skrypty na stronie.

4–5) Omnibox — CVE-2025-12728, CVE-2025-12729 (Medium)

  • Opis: „inappropriate implementation” w Omnibox (pasek adresu). Skutki to m.in. nadużycia UI lub błędne odwzorowanie danych, co w praktyce zwiększa ryzyko phishingu/redirectów i ataków „tapjacking”/„clickjacking” w interakcji z paskiem.

Tabela szybkiego mapowania (CVE → komponent → poziom):
CVE-2025-12725 (WebGPU, High), CVE-2025-12726 (Views, High), CVE-2025-12727 (V8, High), CVE-2025-12728 (Omnibox, Medium), CVE-2025-12729 (Omnibox, Medium).


Praktyczne konsekwencje / ryzyko

  • Atak RCE z poziomu strony: kombinacje luk WebGPU/V8 mogą umożliwić uruchomienie kodu w procesie renderera i potencjalny sandbox escape przy dodatkowych błędach (łańcuchy exploitów).
  • Manipulacja interfejsem i socjotechnika: błędy Omnibox podnoszą skuteczność kampanii phishingowych (maskowanie adresów, nieoczekiwane autouzupełnianie, przekierowania).
  • Ryzyko dla środowisk korporacyjnych: przeglądarka to największa powierzchnia ataku w organizacji; wiele zakładek/aktywnych skryptów zwiększa ekspozycję — stąd presja na szybkie wdrożenia poprawek.

Rekomendacje operacyjne / co zrobić teraz

1) Szybki update użytkownika końcowego

  • Ręcznie (GUI): Ustawienia → Informacje → Google Chrome (sprawdzenie/instalacja, restart).
  • Windows (Winget, CMD/PowerShell jako admin): winget upgrade --id Google.Chrome --source winget $v = (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion Write-Host "Zainstalowana wersja Chrome: $v"
  • macOS (Homebrew): brew update && brew upgrade --cask google-chrome /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
  • Linux (Debian/Ubuntu repo Google): sudo apt update && sudo apt install --only-upgrade google-chrome-stable google-chrome --version

Wersje docelowe: 142.0.7444.134/.135 (w zależności od OS, rollout etapowy).

2) Zarządzanie w organizacji (MDM/Intune/GPO)

  • Wymuś auto-update i restart przeglądarki:
    • GPO (Windows): wgraj najnowsze Chrome ADMX, ustaw:
      • Automatic Browser Updates Enabled = Enabled
      • Target version prefix = 142 (opcjonalnie, aby wymusić min. 142)
      • ComponentUpdatesEnabled = Enabled
      • RelaunchNotification = Required / deadline (np. 24h)
  • Microsoft Intune (Windows/macOS): profil konfiguracyjny z politykami Chrome; ustaw deadline na restart (np. 24–48 h) i Grace Period dla użytkownika.
  • macOS (Jamf/Munki/MDM): Payload z com.google.Keystone (auto-update), polityka wymuszająca relaunch po instalacji.
  • Linux (fleet): repo Google + „pin” wersji, zadanie cron/systemd na aktualizację dzienną.

3) Kontrola zgodności (detekcja niezałatanych hostów)

  • Skany bezpieczeństwa/Nessus/Qualys: użyj wtyczek/QL odpowiadających Chrome 142 (dla macOS/Windows). Przykładowo, Tenable identyfikuje podatność <142.0.7444.135.
  • Szybki skrypt inwentarzowy (Windows/PSRemoting): $computers = Get-Content .\workstations.txt Invoke-Command -ComputerName $computers -ScriptBlock { $p = "C:\Program Files\Google\Chrome\Application\chrome.exe" if (Test-Path $p) { (Get-Item $p).VersionInfo.ProductVersion } else { "Brak Chrome" } }
  • EDR/NDR: stwórz reguły detekcyjne na artefakty exploitów przeglądarkowych (crashe renderera, nieoczekiwane procesy child od Chrome).

4) Hardening przeglądarki (szczególnie do czasu pełnej adopcji)

  • Wyłącz WebGPU w środowiskach o podwyższonym ryzyku (tymczasowo): chrome://flags → Disable WebGPU lub polityka HardwareAccelerationModeEnabled = False (koszt: UX/perf).
  • Ogranicz rozszerzenia: allow-list, audyt uprawnień, blokada developer mode.
  • Zasady izolacji: włącz Site Isolation / Strict Origin Isolation dla aplikacji krytycznych.
  • Zachowania Omnibox: rozważ wyłączenie sugestii i autouzupełniania w stacjach o podwyższonym ryzyku (polityki Omnibox).

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

  • Brak zero-day w tej fali (w odróżnieniu od poprzednich wydań z 2025 r., gdzie V8 bywał wykorzystywany „in the wild”). Obecna łatka dotyczy nowych CVE w 142 i nie ma wzmianki o aktywnej eksploatacji.
  • Komponenty: ponownie widzimy mieszankę błędów pamięci (WebGPU/V8) i błędów implementacyjnych UI (Views/Omnibox), co odpowiada trendom w złożonych przeglądarkach (warstwy grafiki + interfejs).

Podsumowanie / kluczowe wnioski

  • Zaktualizuj Chrome do 142.0.7444.134/.135 jak najszybciej; zdefiniuj deadline i wymuszony relaunch.
  • Monitoruj zgodność — hosty poniżej 142.0.7444.134/.135 są podatne; skanuj i raportuj odsetek niezałatanych.
  • Zarządzaj ryzykiem WebGPU/Omnibox (tymczasowe wyłączenia/ograniczenia), szczególnie w stacjach z wysoką ekspozycją web/AI.

Źródła / bibliografia

  1. Chrome Releases – Stable Channel Update for Desktop (142.0.7444.134/.135, 5 CVE, rollout i restrykcje szczegółów). (Chrome Releases)
  2. SecurityWeek – „Chrome 142 Update Patches High-Severity Flaws” (CVE, opis WebGPU, brak „in the wild”). (SecurityWeek)
  3. Tenable – Nessus Plugin 274070 (detekcja hostów <142.0.7444.135, lista CVE). (Tenable®)
  4. Chrome for Developers – Release notes 142 (data stabilnego wydania 28.10.2025). (Chrome for Developers)
  5. FortiGuard – wpis zbiorczy o lukach w Chrome 142 (mapowanie CVE/komponentów). (fortiguard.com)

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)