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

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)

CVE-2013-1493 — Oracle Java SE (2D/CMM) RCE przez obraz rastrowy

TL;DR

Krytyczna luka w Java SE 5/6/7 (moduł 2D/CMM) umożliwia zdalne wykonanie kodu przy przetwarzaniu spreparowanego obrazu rastrowego w aplecie/Java Web Start. W 2013 r. była aktywnie wykorzystywana w kampaniach drive‑by (np. pakiety exploitów), a Oracle załatał ją w JRE/JDK 7u17 i 6u43. Dla SOC mapujemy to na T1189 (wejście przez stronę WWW) oraz T1203 (eksploatacja klienta). Zalecane: odinstalować wtyczkę Java w przeglądarkach (legacy), wymusić aktualizacje, monitorować łańcuch browser → java.exe → LOLBIN.


Krótka definicja techniczna

CVE‑2013‑1493 to błąd w Color Management (CMM) komponentu Java 2D, który przy przetwarzaniu obrazu o specjalnie przygotowanych parametrach rastra powoduje odczyt poza buforem i/lub uszkodzenie pamięci JVM, co umożliwia RCE przez aplet/Java Web Start w przeglądarce. CVSS v2: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C).


Gdzie występuje / przykłady platform

  • Endpointy z przeglądarką i wtyczką Java: Windows, macOS, Linux (w 2013 r. powszechne; dziś przeważnie legacy/ICS/offline).
  • Środowiska VDI/kioski z dziedziczonymi aplikacjami Web Start.
  • Nie dotyczy bezpośrednio serwerów (Oracle: luka dotyczy Javy uruchamianej w przeglądarce).

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

Atakujący umieszcza na stronie WWW (lub w pakiecie exploitów) aplet/Java Web Start wczytujący obraz z nietypowymi parametrami rastra. Podczas renderowania w module Java 2D/CMM dochodzi do naruszenia pamięci JVM → przekazanie sterowania do złośliwego payloadu. W typowym łańcuchu drive‑by użytkownik odwiedza stronę (często watering hole), przeglądarka ładuje wtyczkę Java, a po eksploatacji następuje pobranie i uruchomienie kolejnego modułu (np. downloader), często z wykorzystaniem systemowych LOLBIN‑ów (cmd.exe, powershell.exe, rundll32.exe). Oracle podkreślał, że lukę należy traktować jako dotyczącą Javy w przeglądarkach (nie serwerowej).

Dlaczego skuteczna (historycznie):

  • masowa ekspozycja wtyczki Java w przeglądarkach;
  • niska interakcja użytkownika (często brak – lub akceptacja ostrzeżenia);
  • natychmiastowe przejście do Execution po Initial Access (ATT&CK).

Artefakty i logi

ŹródłoID / typCo obserwowaćWskazówki
Windows Security4688 (Process Create)java.exe/javaw.exe/javaws.exe jako dziecko chrome.exe/msedge.exe/firefox.exe/iexplore.exeNietypowe dziś; silnie podejrzane w 2025 r.
Sysmon1 (Process Create)java*.exe → uruchamia cmd.exe/powershell.exe/wscript.exe/rundll32.exe/mshta.exeŁańcuch post‑eksploatacyjny
Sysmon3 (Network Connect), 22 (DNS)Połączenia HTTP(S) zaraz po starcie java.exe do nieznanych domen; rzadkie SNI/JA3Korelować z Proxy/NGFW
Sysmon7 (ImageLoad)Dynamiczne DLL do Javy ładowane z %TEMP%/%APPDATA%Droppery
Sysmon11 (FileCreate)Nowe JAR/EXE/DLL w profilach użytkownikaArtefakty post‑eksploatacyjne
Proxy/HTTPPobrania .jar/.class/MIME application/java-archive, stare typy application/x-java-appletWzorzec drive‑by
EDR (MDE/SentinelOne/itp.)Reguły behawioralne: przeglądarka → Java → LOLBIN → siećKorelacje
CloudTrail (S3 data events)GetObjectPobrania .jar/.class z bucketów spoza allowlistyDetekcja hostingu artefaktów
K8s audit[N/D] — luka dot. klienta przeglądarkowego
M365 Audit[N/D] — brak bezpośredniego śladu

Detekcja (praktyczne reguły)

Sigma (Windows / Sysmon)

title: Browser-Spawns-Java-And-Java-Spawns-LOLBIN (CVE-2013-1493 TTP)
id: 9b9a6e2f-9a1c-4bde-b3d9-13d313493000
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  browser_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
  java_proc:
    Image|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\javaws.exe'
  lolbin_child:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\javaws.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\mshta.exe'
  condition: (browser_parent and java_proc) or lolbin_child
fields:
  - UtcTime
  - Image
  - ParentImage
  - CommandLine
  - ParentCommandLine
falsepositives:
  - Rzadkie, legacy Web Start / środowiska deweloperskie
level: high
tags:
  - attack.T1189
  - attack.T1203

Splunk (SPL)

1) Przeglądarka → Java

index=sysmon sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1
| where mvfind(["chrome.exe","msedge.exe","firefox.exe","iexplore.exe"], lower(coalesce(ParentImage,ParentImage)))>=0
| where like(lower(Image), "%\\java.exe") OR like(lower(Image), "%\\javaw.exe") OR like(lower(Image), "%\\javaws.exe")
| stats earliest(_time) as firstSeen latest(_time) as lastSeen values(CommandLine) by Computer, User, ParentImage, Image, ParentCommandLine

2) Java → podejrzany LOLBIN / łańcuch procesu

index=sysmon EventCode=1 (Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\rundll32.exe" OR Image="*\\mshta.exe")
| join ProcessGuid type=inner [
  search index=sysmon EventCode=1 (Image="*\\java.exe" OR Image="*\\javaw.exe" OR Image="*\\javaws.exe")
  | table ProcessGuid, Computer, User, Image, ParentImage, CommandLine, ParentCommandLine, _time
]
| table _time, Computer, User, ParentImage, Image, CommandLine, ParentCommandLine

KQL (Microsoft Defender/Sentinel)

// Browser -> Java
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe","iexplore.exe")
| where FileName in~ ("java.exe","javaw.exe","javaws.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName

// Java -> LOLBIN within 2 min
let suspiciousChildren = dynamic(["cmd.exe","powershell.exe","wscript.exe","rundll32.exe","mshta.exe"]);
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("java.exe","javaw.exe","javaws.exe")
| join kind=inner (
    DeviceProcessEvents
    | where FileName in~ (suspiciousChildren)
    | project ChildTime=Timestamp, DeviceId, ChildFile=FileName, ChildCmd=ProcessCommandLine, InitiatingProcessParentId
) on DeviceId, InitiatingProcessId==InitiatingProcessParentId
| where ChildTime between (Timestamp .. Timestamp + 2m)
| project DeviceName, Timestamp, ChildTime, InitiatingProcessFileName, ChildFile, ChildCmd

CloudTrail query (CloudWatch Logs Insights – S3 Data Events)

Użyteczne, gdy wykrywamy hostowanie artefaktów JAR/CLASS w S3 (częsty etap w kampaniach drive‑by).

fields @timestamp, eventSource, eventName, requestParameters.bucketName, requestParameters.key, sourceIPAddress, userAgent
| filter eventSource = "s3.amazonaws.com" and eventName = "GetObject"
| filter requestParameters.key like /\.jar$/ or requestParameters.key like /\.class$/
| filter ispresent(userAgent) and (userAgent like 'Mozilla%' or userAgent like '%Java%')
| sort @timestamp desc

Elastic / EQL (Endpoint)

// Java spawns LOLBIN
process where
  process.name in ("cmd.exe","powershell.exe","wscript.exe","rundll32.exe","mshta.exe") and
  parent.process.name in ("java.exe","javaw.exe","javaws.exe")

Heurystyki / korelacje

  • Łańcuch czasowy: browser → java.exe → LOLBIN → outbound HTTP(S)/DNS w krótkim oknie (≤2 min).
  • Pliki tymczasowe: nowe .jar/.dll/.exe w %TEMP%, %APPDATA%, ~/Library/Application Support.
  • Proxy/NGFW: nagłe pobrania JAR/CLASS z rzadkich domen → brak wcześniejszej reputacji.
  • EDR: zastrzyk modułów do JVM spoza katalogów Javy; Java jako nietypowy rodzic skryptów/LOLBIN‑ów.
  • Reputacja/Threat Intel: korelacja domen/IP z historycznymi pakietami exploitów (Blackhole/Sweet Orange itd.).

False positives / tuning

  • Legitymne środowiska Web Start/IcedTea‑Web (intranety, ICS) — białe listy domen/aplikacji.
  • Deweloperzy Javy uruchamiający narzędzia buildujące z przeglądarki.
  • W 2025 r. każde uruchomienie wtyczki Java w przeglądarce jest podejrzane; tuning opierać na allowlistach domen i podpisów plików JAR.

Playbook reagowania (IR)

  1. Triage i izolacja: odłącz host, zachowaj pamięć/dysk (artefakty JVM).
  2. Zbieranie faktów: drzewo procesów od przeglądarki do java*.exe, następnie do LOLBIN‑ów; zrzut listy modułów JVM; lista nowo utworzonych plików.
  3. Sieć: zablokuj domeny/sumy SHA256 pobranych JAR/EXE; sprawdź proxy dla innych ofiar.
  4. Eskalacja/przeciwdziałanie:
    • odinstaluj/wyłącz plugin Java;
    • wymuś aktualizacje do JRE/JDK 7u17/6u43 na hostach legacy; rozważ całkowite usunięcie Javy z przeglądarek.
  5. Hunting retro (30–90 dni): wzorce pobrań .jar/.class, łańcuchy browser → Java → LOLBIN.
  6. Lessons learned: polityka click‑to‑play / blokada wtyczek, patch management, segmentacja egress.

Przykłady z kampanii / case studies

  • Blackhole i inne pakiety exploitów (2013) szeroko nadużywały luk w Javie, w tym CVE‑2013‑1493, do drive‑by download i pobierania malware.
  • Detekcje vendorów (MSFT) klasyfikowały ruch jako Exploit:Java/CVE‑2013‑1493 – wejście przez stronę WWW, następnie pobranie i uruchomienie plików.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w odizolowanym, testowym środowisku (VM, brak Internetu). Celem jest wygenerowanie artefaktów detekcyjnych, nie eksploatacja luki.

A. Symulacja łańcucha browser → Java

  1. Otwórz w przeglądarce lokalny plik HTML z linkiem jnlp (pusty, benigny) albo uruchom:
# Windows (zainstalowana Java): symulacja startu Java z procesu użytkownika
Start-Process -FilePath "$env:ProgramFiles\Google\Chrome\Application\chrome.exe" -ArgumentList "about:blank"
Start-Sleep -Seconds 2
Start-Process -FilePath "C:\Program Files\Java\jre\bin\javaw.exe" -ArgumentList "-version"
  1. Sprawdź, czy reguły Sigma/Splunk/KQL łapią „browser → javaw.exe”.

B. Java → LOLBIN (benigny helper)
Utwórz prosty JAR uruchamiający notepad (tylko logówka):

# Linux/macOS (analogicznie w Windows z javac)
cat > Runner.java << 'EOF'
public class Runner {
  public static void main(String[] args) throws Exception {
    new ProcessBuilder("notepad.exe").start(); // na *nix np. "xcalc"
  }
}
EOF
javac Runner.java && jar cfe runner.jar Runner Runner.class
# Uruchom:
java -jar runner.jar

Oczekiwany artefakt: java.exe → notepad.exe (LOLBIN), co powinno trafić w reguły.


Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 – Update Software (patchowanie Javy; eliminacja wtyczki/legacy)
  • M1031 – Network Intrusion Prevention (blok sygnatur exploit‑kit/JAR)
  • M1040 – Behavior Prevention on Endpoint (EDR/anty‑exploit)
  • M1017 – User Training (świadomość ryzyk apletów/ostrzeżeń przeglądarki)

Powiązane techniki:

  • T1189 Drive‑by Compromise (wejście)
  • T1203 Exploitation for Client Execution (RCE w kliencie)
  • T1204.002 User Execution: Malicious File (czasem wymagane kliknięcie/akcept)
  • T1059 Command and Scripting Interpreter (następstwa)

Źródła / dalsza literatura

  • Oracle Security Alert (zakres: dotyczy Javy w przeglądarkach; wersje naprawcze 7u17/6u43) (Oracle)
  • Oracle JDK 7u17 Release Notes (baseline wersji z poprawką) (Oracle)
  • NVD CVE‑2013‑1493 (opis techniczny, CVSS 10.0, „exploited in the wild”) (NVD)
  • CISA Alert: Oracle Java Contains Multiple Vulnerabilities (wersje podatne i zalecenia) (CISA)
  • Microsoft WDSI – Exploit:Java/CVE‑2013‑1493 (mechanika ataku przez WWW) (Microsoft)
  • McAfee Labs (pakiety exploitów wykorzystywały m.in. CVE‑2013‑1493) (McAfee)
  • ATT&CK – T1189 / T1203 / TA0001 / TA0002 / v18 updates (mapowanie technik i wersja ATT&CK) (MITRE ATT&CK)

Checklisty dla SOC / CISO (krótko)

SOC (operacyjne):

  • Włączone logi: Sysmon (1/3/7/11/22), Security 4688, EDR z korelacją rodzic‑dziecko.
  • Reguły: „browser → java.exe”, „java.exe → LOLBIN”, pobrania .jar/.class.
  • Blokady: domeny/URL z kampanii, Content‑Type application/java-archive.
  • Hunting retro: 30–90 dni w proxy/EDR pod kątem JAR/CLASS + łańcuch procesów.
  • Alerting na dowolne uruchomienie wtyczki Java w przeglądarce (2025).

CISO (strategiczne):

  • Eliminacja wtyczek Java (NPAPI) w organizacji; akceptacja wyjątków tylko czasowa.
  • Polityka patchowania: min. 7u17/6u43 na systemach legacy lub migracja/wycofanie.
  • EDR z prewencją behawioralną (M1040) i IPS przy egress (M1031).
  • Program świadomości (M1017) dot. apletów/ostrzeżeń przeglądarki.


Uwaga o ryzyku: Choć wtyczka Java jest powszechnie wycofana we współczesnych przeglądarkach, luka ma znaczenie historyczne, a wewnętrzne środowiska legacy (np. ICS/offline) mogą wciąż generować analogiczne ścieżki ataku.
Rekomendacja: najlepiej całkowicie usunąć wtyczkę Java z przeglądarek i ograniczyć Javę do aplikacji lokalnych z aktualną wersją JVM.

GlassWorm znowu na OpenVSX: trzy nowe rozszerzenia VS Code z ukrytym malware

Wprowadzenie do problemu / definicja luki

Na OpenVSX (alternatywny rejestr rozszerzeń VS Code) wykryto powrót kampanii GlassWorm – zestawu złośliwych rozszerzeń wykorzystujących niewidzialne znaki Unicode do ukrywania i wykonywania JavaScriptu. Nowa fala obejmuje 3 rozszerzenia (m.in. ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs) i według bieżących raportów odnotowała łącznie >10 tys. pobrań. Kampania kontynuuje wcześniej opisane techniki: C2 w łańcuchu Solana, kradzież tokenów GitHub/npm/OpenVSX oraz danych portfeli krypto z 49 popularnych wtyczek.


W skrócie

  • Co się stało: po październikowych czyszczeniach OpenVSX znów pojawiły się 3 zainfekowane rozszerzenia z ukrytym ładunkiem GlassWorm.
  • Jak działa: payload jest schowany w znakach PUA/VS (Private Use Area/Variation Selectors) – „puste” w edytorze, ale dekodowane i wykonywane przez JS. C2 i aktualizacje są osadzane w transakcjach Solana (trwałość, anonimizacja, niskie koszty).
  • Po co: kradzież sekretów (GitHub, npm, OpenVSX), drenaż krypto, tworzenie SOCKS proxy/HVNC i budowa infrastruktury przestępczej na stacjach devów.
  • Skala i spór: OpenVSX informował, że incydent z października był „opanowany” i że nie była to autonomiczna samoreplikacja; jednak badacze widzą „samopowielanie” przez kradzież i użycie poświadczeń.
  • Nowość: potwierdzone wejście na GitHub (commity z doklejonym, ukrytym dekoderem + eval) – to rozszerza wektor poza marketplace.

Kontekst / historia / powiązania

Pierwsza fala GlassWorm została opisana 20 października 2025 r., gdy wykryto pakiet zainfekowanych rozszerzeń na OpenVSX i w marketplace Microsoftu (łączny licznik pobrań szacowany na ok. 35,8 tys., choć mógł być sztucznie zawyżony przez atakujących). 2 listopada OpenVSX ogłosił rotację tokenów i dodatkowe zabezpieczenia po wykryciu wycieku >550 sekretów; jednocześnie podkreślił, że kod nie był „samoreplikującym się” robakiem w klasycznym sensie. 6 listopada badacze Koi i Aikido pokazali jednak nową falę oraz pivot na GitHub. 8 listopada media potwierdziły trzy świeże rozszerzenia na OpenVSX.


Analiza techniczna / szczegóły luki

1) „Niewidzialny” ładunek

  • Atak wykorzystuje PUA/VS (np. zakresy U+E000–U+F8FF, U+FE00–U+FE0F), które nie renderują się w edytorze, ale są parsowane przez dekoder w JS. Typowy wzorzec: dekoder mapujący punkty kodowe → bajty → eval. Na GitHub widziano jednolinijkowy wariant, który dołączał dekoder na końcu pliku.

2) Kanał C2/aktualizacji w Solanie

  • Rozszerzenia pobierają następne etapy na podstawie transakcji Solana (w polach danych trzymane są base64 z URL-ami serwerów C2). Rozwiązanie trudne do zdejmowania (odporne, tanie, anonimowe). Backup: Google Calendar z linkiem base64 w tytule wydarzenia.

3) Zdolności końcowe

  • Kradzież tokenów/logowań (GitHub/npm/OpenVSX), portfeli krypto (49 wtyczek), uruchamianie SOCKS proxy, HVNC (ukryty VNC) – praktycznie przejęcie stacji deweloperskiej jako węzła przestępczego.

4) Infrastruktura i IOC

  • Koi w nowej fali wskazało, że używana jest ta sama infrastruktura (zaktualizowane wskaźniki C2 publikowane w Solanie; przykładowo w raporcie widnieją adresy 199.247.10.166 oraz 199.247.13.106:80/wall jako punkty komunikacji/eksfiltracji).

Praktyczne konsekwencje / ryzyko

  • Łańcuchowe kompromitacje: kradzione tokeny wydawnicze pozwalają wstrzykiwać złośliwe aktualizacje do innych rozszerzeń/repozytoriów/teamów.
  • Trwałość i trudne wyłączenie: C2 na blockchainie zmniejsza skuteczność klasycznych Takedownów. Zmiana transakcji → nowy endpoint → „samoleczenie” C2.
  • Ryzyko finansowe i reputacyjne: wyciek sekretów organizacji, kradzież krypto, nadużycie zasobów (proxy, botnet z dev-workstation).
  • Rozszerzenie wektora: pojawienie się ukrytych commitów na GitHub (AI-like, wiarygodne modyfikacje) utrudnia code review i detekcję.

Rekomendacje operacyjne / co zrobić teraz

0) Szybkie kroki IR (dla SOC/ITSec)

  1. Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
    • ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs.
  2. Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
  3. Rotuj sekrety: patche PAT/ghp, npm tokens, OpenVSX tokens, klucze do CI/CD; wymuś 2FA i SSO. (OpenVSX przeszedł już rotację tokenów, ale Twoja organizacja musi zrobić to samo).

1) Wykrywanie „niewidzialnego” kodu (proste skrypty)

Linux/macOS – skan katalogów rozszerzeń VS Code/VSCodium

# VS Code i VSCodium: typowe ścieżki
EXT_DIRS=("$HOME/.vscode/extensions" "$HOME/.vscode-oss/extensions" "$HOME/.vscode-insiders/extensions")
# Znaki PUA/VS: U+E000–U+F8FF, U+FE00–U+FE0F, U+E0100–U+E01EF
for d in "${EXT_DIRS[@]}"; do
  [ -d "$d" ] || continue
  echo "[*] Skanuję $d"
  grep -RIl --include='*.js' --include='*.ts' \
    -P "[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]" "$d" || true
done

Windows (PowerShell)

$paths = @("$env:USERPROFILE\.vscode\extensions", "$env:USERPROFILE\.vscode-oss\extensions")
$pattern = '[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]'
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem -Recurse -Include *.js,*.ts -Path $p |
      Select-String -Pattern $pattern -AllMatches | Select-Object Path,LineNumber
  }
}

Prosty YARA snippet (heurystyka):

rule Invisible_Unicode_PUA_Eval_JS {
  meta: author="BlueTeam" description="GlassWorm-like hidden code"
  strings:
    $pua = /[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]+/u
    $eval = /eval\s*\(/ nocase
  condition:
    uint16(0) == 0xFFFE or uint16(0) == 0xFEFF or filesize < 5MB and $pua and $eval
}

2) Usuwanie podejrzanych rozszerzeń

# VS Code
code --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
code --uninstall-extension ai-driven-dev.ai-driven-dev
code --uninstall-extension adhamu.history-in-sublime-merge
code --uninstall-extension yasuyuky.transient-emacs

# VSCodium
codium --list-extensions | grep -E "ai-driven-dev|sublime-merge|transient-emacs"
codium --uninstall-extension ai-driven-dev.ai-driven-dev
...

3) Twardnienie łańcucha wydawniczego

  • Sekrety: ogranicz TTL tokenów, wprowadź krótko żyjące PAT, automatyczną re-rotację po wykryciu wycieku; secret scanning w CI. (Zgodne z kierunkiem zmian deklarowanych przez OpenVSX).
  • Publikacja rozszerzeń: SBOM + skan artefaktów przed publikacją, signowanie, zasada 4-oczu na „release”.
  • Review kodu: wymuś widoczność znaków niewidzialnych w IDE i Diffach (np. włącz „Render Control Characters” w VS Code, używaj pre-commit hooków skanujących PUA). (W raporcie Aikido wskazano, że interfejsy nie zawsze oznaczały te znaki).
  • Egress i DNS: blokady do znanych IOC oraz monitorowanie zapytań powiązanych z Solaną używaną jako kanał C2 (telemetria proxy, NetFlow/Zeek).

Różnice / porównania z innymi przypadkami

  • Klasyczne „tylne drzwi” w npm (post-install, skrypty lifecycle) były wyraźniejsze w kodzie; tutaj ładunek „nie istnieje gołym okiem” i potrafi przenikać code review.
  • C2 w Solanie to nowszy trend utrudniający Takedown – w porównaniu do typowych domen/URL na VPS, które łatwiej zawiesić.
  • Spór o „worma”: OpenVSX wskazuje, że brak autonomicznej replikacji; badacze argumentują, że automatyczne aktualizacje + wykorzystanie wykradzionych tokenów de facto umożliwia rozprzestrzenianie się w ekosystemie. Wniosek operacyjny: dla obrony nie ma to znaczenia – ścieżka propagacji i tak omija kontrole.

Podsumowanie / kluczowe wnioski

  • Niewidzialny kod + blockchain C2 + kradzież sekretów = bardzo skuteczny model ataku na ekosystemy developerskie.
  • Nowa fala na OpenVSX pokazuje, że nawet po rotacji tokenów atakujący szybko wracają – potrzebne są krótkie TTL, skanowanie podczas publikacji i silne procesy w organizacjach.
  • Blue Teamy powinny wdrożyć skan PUA, bloki IOC, telemetrię egress i procedury IR wyspecjalizowane dla stacji developerskich (zależne od IDE/marketplace).

Źródła / bibliografia

  1. BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
  2. BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
  3. Eclipse Foundation (OpenVSX) – aktualizacja bezpieczeństwa, rotacje tokenów i stanowisko nt. „self-replicating” (27.10.2025; podsumowane także 02.11.2025). (Eclipse Foundation Staff Blogs)
  4. Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
  5. Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)

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”

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

Wprowadzenie do problemu / definicja luki

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


W skrócie

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

Kontekst / historia / powiązania

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


Analiza techniczna / szczegóły luki

Składniki łańcucha ataku:

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

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

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

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

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

2) Kontrola instalacji i inwentaryzacja

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

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

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

4) Hardening stacji developerskich

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

5) Reagowanie i odtwarzanie

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

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

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

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

Wprowadzenie do problemu / definicja luki

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


W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły luki

Wektor: złośliwy plik DNG

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

Łańcuch infekcji (wysoki poziom)

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

Kluczowe pliki/ścieżki i artefakty

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

Zdolności spyware (wybór)

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania IT/MDM

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

2) Detekcja i hunting (przykłady)

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

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

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

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

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

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

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

3) Hardening i polityki

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

4) Reagowanie incydentowe (skrót)

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

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

Wprowadzenie do problemu / definicja luki

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


W skrócie

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

Kontekst / historia / powiązania

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


Analiza techniczna / szczegóły luki

Zakres i komponenty

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

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


Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacje – minimalne wersje docelowe

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

2) Szybkie kroki higieniczne (post-patch)

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

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

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

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

4) Hardening usług backupu (HBS 3)

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

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

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

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

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

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

Różnice / porównania z innymi przypadkami

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


Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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