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

QNAP łata luki wykorzystane na Pwn2Own Ireland 2025: co musisz zaktualizować i jak zabezpieczyć NAS

Wprowadzenie do problemu / definicja luki

QNAP opublikował pakiet poprawek dla ~24 podatności w swoim portfolio, z czego 7 to 0-daye zademonstrowane podczas Pwn2Own Ireland 2025 (kategoria NAS/SoHo). W grze są zarówno systemy QTS/QuTS hero, jak i aplikacje o wysokich uprawnieniach: HBS 3 (Hybrid Backup Sync), Malware Remover oraz Hyper Data Protector. Skutki obejmują zdalne wykonanie kodu (RCE), ujawnienie informacji, ominięcie mechanizmów bezpieczeństwa oraz DoS. Aktualizacje są już dostępne i powinny zostać wdrożone niezwłocznie.


W skrócie

Minimalne wersje naprawcze:

  • QTS: 5.2.7.3297 (build 20251024+)
  • QuTS hero: h5.2.7.3297+ lub h5.3.1.3292+
  • HBS 3: 26.2.0.938+ (CVE-2025-62840, CVE-2025-62842)
  • Malware Remover: 6.6.8.20251023+ (CVE-2025-11837)
  • Hyper Data Protector: 2.2.4.1+ (CVE-2025-59389)

Po aktualizacji QNAP zaleca zmianę wszystkich haseł do kont i usług.


Kontekst / historia / powiązania

Na Pwn2Own Ireland 2025 zaprezentowano szereg łańcuchów ataku na QNAP. Team DDOS wykazał m.in. łańcuch 8 błędów na routerach i NAS-ach QNAP (nagroda 100 tys. USD), a DEVCORE skleił kilka podatności (iniekcje + błąd formatu) zdobywając 40 tys. USD. Summoning Team i badacz Chumy Tsai (CyCraft) pokazali kolejne wektory w aplikacjach backupowych. QNAP opublikował odpowiednie biuletyny bezpieczeństwa i patche.


Analiza techniczna / szczegóły luki

Zakres i klasy podatności (przykładowe):

  • QTS / QuTS hero – zestaw 3 błędów (m.in. iniekcje i format string), umożliwiający RCE / eskalację w określonych warunkach. Naprawione w QTS 5.2.7.3297 i odpowiednich buildach QuTS hero. (Atrybucja: DEVCORE).
  • HBS 3 (Hybrid Backup Sync) – dwa błędy (m.in. w ścieżkach wykonywania zadań backupu/synchronizacji), które w łańcuchach ataku pozwalały na zdalne wykonanie kodu i manipulację treścią kopii (CVE-2025-62840, CVE-2025-62842). Załatane w 26.2.0.938.
  • Malware Remover – krytyczny code injection (CVE-2025-11837); komponent działa z wysokimi uprawnieniami, więc RCE skutkuje przejęciem NAS-a. Patch: 6.6.8.20251023.
  • Hyper Data Protector – krytyczna podatność (CVE-2025-59389) pozwalająca na kompromitację hosta backupu VM; naprawiona w 2.2.4.1.

Dowód eksploatacji na Pwn2Own (fragmenty łańcuchów, nagrody, celowane modele jak TS-453E) został odnotowany w raportach ZDI z poszczególnych dni konkursu.


Praktyczne konsekwencje / ryzyko

  • Zatrucie i sabotaż kopii zapasowych: przejęcie HBS 3 umożliwia modyfikację/wymazywanie danych w repozytoriach off-site (rsync/S3/SMB/WebDAV), co może zniweczyć strategię 3-2-1 i utrudnić odtworzenie po incydencie.
  • Eskalacja uprawnień przez komponenty zaufane: Malware Remover i Hyper Data Protector działają z uprawnieniami systemowymi; ich kompromitacja = pełne RCE i potencjalny lateral movement do hipernadzorców/serwerów wirtualizacji.
  • Brak sygnałów o atakach „in the wild” na moment publikacji, ale historia QNAP pokazuje, że luki w NAS-ach szybko stają się celem grup ransomware/botnetów – dlatego czas reakcji ma krytyczne znaczenie.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja systemu i aplikacji

  • GUI (zalecane):
    Panel sterowania → SystemAktualizacja oprogramowania (QTS/QuTS hero).
    App Center → wyszukaj: HBS 3, Malware Remover, Hyper Data ProtectorUpdate.
    Wersje docelowe: patrz sekcja „W skrócie”.
  • CLI (sprawdzenie wersji QPKG):
# Na QNAP (BusyBox). Odczyt z /etc/config/qpkg.conf
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

2) Po aktualizacji – zmień hasła

Zmień hasła do wszystkich kont lokalnych, myQNAPcloud, udziałów i usług (rsync/FTP/SMB/WebDAV), rozważ też rotację kluczy/API używanych przez zadania HBS 3. Rekomendacja producenta po wdrożeniu poprawek.

3) Ogranicz ekspozycję NAS-a

  • Wyłącz bezpośredni dostęp z Internetu (port-forwarding, UPnP).
  • Używaj VPN/ZTN do administracji; reguły QuFirewall: whitelisting IP/Admin, geo-IP, blokada nietypowych portów.

4) Utwardzenie aplikacji backupu

  • HBS 3: stosuj repozytoria WORM/immutable, wersjonowanie, testy odtwarzania (restore drills).
  • Hyper Data Protector: separuj konta serwisowe (najmniejsze uprawnienia), monitoruj logi z zadaniami VM.

5) Monitoring i detekcja (przykładowe sygnały do SIEM)

  • Nietypowe modyfikacje zadań HBS 3 (nagłe zmiany destynacji/S3 bucket).
  • Nowe konta admin lub rotacja haseł poza oknem serwisowym.
  • Wywołania skryptów/system() przez procesy QPKG (próby RCE).

Wskazówka: jeśli nie możesz patchować natychmiast, przynajmniej wyłącz HBS 3/Hyper Data Protector/ekspozycję WAN i odizoluj NAS segmentacją.


Różnice / porównania z innymi przypadkami

  • W odróżnieniu od dawnych, pojedynczych RCE w panelach WWW NAS-ów, tutaj „gorącym” celem są aplikacje backupowe (HBS 3, Hyper Data Protector) – ich kompromitacja daje większą dźwignię: modyfikacja kopii, pivot do hostów wirtualizacji, niszczenie ścieżek odtworzeniowych.
  • Łańcuchy na Pwn2Own (złożone exploity, łączenie iniekcji z błędami formatu/uwierzytelniania) pokazują rosnącą złożoność ataku i wartość testów red team/bug bounty dla dostawców.

Podsumowanie / kluczowe wnioski

  1. Patch first: QTS/QuTS hero + HBS 3 + Malware Remover + Hyper Data Protector do wersji wskazanych powyżej.
  2. Zmień hasła i klucze natychmiast po aktualizacji.
  3. Zamknij ekspozycję WAN i wymuś administrację przez VPN/ZTN.
  4. Zabezpiecz backup (immutability, testy restore, konta o najmniejszych uprawnieniach).
  5. Monitoruj anomalie w zadaniach backupu i logach QPKG.

To nie jest „zwykły” patch Tuesday – dotyczy komponentów, które decydują o przetrwaniu incydentu (backup i odtwarzanie). Działaj od razu.


Źródła / bibliografia

  • SecurityWeek – przegląd poprawek QNAP po Pwn2Own Ireland 2025 (daty, CVE, wersje) (SecurityWeek)
  • QNAP QSA-25-46 – Multiple Vulnerabilities in HBS 3 Hybrid Backup Sync (wersja 26.2.0.938+) (qnap.com)
  • QNAP QSA-25-47 – Vulnerability in Malware Remover (CVE-2025-11837; 6.6.8.20251023+) (qnap.com)
  • QNAP QSA-25-48 – Vulnerability in Hyper Data Protector (CVE-2025-59389; 2.2.4.1+) (qnap.com)
  • ZDI – Pwn2Own Ireland 2025 (wyniki dzienne; potwierdzenie łańcuchów i nagród) (zerodayinitiative.com)

Wykrywanie Honeypotów – Metody, Narzędzia, Obrona

Honeypoty też mają odciski palców

Honeypoty (komputerowe wabiki) są potężnym narzędziem obrony – przyciągają atakujących niczym cyber-pułapki, dając wgląd w ich techniki. Nic dziwnego, że agresorzy starają się je wykrywać i omijać. W tym artykule przyjrzymy się technikom honeypot detection, czyli metodom rozpoznawania czy dany system to prawdziwy cel, czy sprytnie zastawiona pułapka. Omówimy fingerprinting aktywny i pasywny, zdradliwe sygnały (banery, błędy protokołów, cechy stosu TCP/IP, certyfikaty TLS), narzędzia wykorzystywane zarówno przez red team (atakujących) jak i blue team (obrońców) oraz metody obrony honeypotów przed dekonspiracją. Przygotujcie się na techniczne szczegóły, przykłady z narzędzi w stylu curl/nmap oraz konkretne porady gotowe do wdrożenia w labie i produkcji.

Czytaj dalej „Wykrywanie Honeypotów – Metody, Narzędzia, Obrona”

Manassas (VA): zamknięcie szkół MCPS po incydencie cybernetycznym — co wiemy i jak reagować operacyjnie

Wprowadzenie do problemu / definicja incydentu

W niedzielę, 9 listopada 2025 r., dystrykt Manassas City Public Schools (MCPS) w stanie Wirginia poinformował o incydencie cyberbezpieczeństwa, który spowodował zakłócenia łączności i niedostępność systemów telefonicznych. W konsekwencji wszystkie szkoły zostały zamknięte w poniedziałek, 10 listopada, aby umożliwić zespołom IT zabezpieczenie i przywracanie usług. Władze dystryktu podkreśliły, że bezpieczeństwo fizyczne kampusów nie było zagrożone.

Informacja o zamknięciu została odnotowana również przez inne lokalne media, które powołują się na list do rodzin podpisany przez superintendenta dr. Kevina Newmana. Wskazano, że incydent miał miejsce w weekend i jest w toku analizy.


W skrócie

  • Co się stało: incydent cybernetyczny zakłócił pracę systemów sieciowych i telefonicznych MCPS. Szkoły zamknięto w poniedziałek (10.11.2025).
  • Komunikacja: dystrykt przekazał informację rodzinom/uczniom, m.in. kanałami społecznościowymi i mediami lokalnymi; zaznaczono brak zagrożenia dla bezpieczeństwa fizycznego.
  • Status techniczny: trwa przywracanie usług; priorytetem jest odtworzenie łączności i telekomunikacji.
  • Szerszy trend: liczba ataków na sektor edukacji jest wysoka; w 2024 r. odnotowano 116 zaatakowanych dystryktów K-12 w USA, a w 2025 r. branżowe raporty wskazują utrzymującą się presję grup ransomwarowych.

Kontekst / historia / powiązania

Region północnej Wirginii ma świeże doświadczenia z podobnymi zdarzeniami: w sierpniu 2025 r. Manassas Park City Schools (MPCS) ogłosił po incydencie ransomware możliwe naruszenie danych, choć jest to odrębny dystrykt od MCPS (Manassas City). Ten przypadek pokazuje, że lokalna oświata jest celem ciągłej aktywności wrogich grup. (Uwaga: przytaczane wyłącznie jako kontekst regionalny, nie jako powiązanie techniczne.) (

Równolegle, statystyki branżowe (Emsisoft 2024) i przeglądy dla oświaty (K12 Dive 2025) potwierdzają trend zwiększonej liczby incydentów i aktywności grup ransomware w sektorze edukacji.


Analiza techniczna / szczegóły luki

Publicznie dostępne informacje nie wskazują jeszcze na konkretny wektor ataku ani rodzinę malware/ransomware w przypadku MCPS. Poniższa analiza przedstawia najbardziej prawdopodobne ścieżki kompromitacji w K-12 na podstawie aktualnych trendów (do zastosowania przy triage i threat huntingu).

Najczęstsze wektory w K-12 (2024–2025):

  1. Phishing / BEC → uzyskanie poświadczeń do M365/Google Workspace; pivot przez VPN/SSO.
  2. Eksploatacja urządzeń brzegowych (VPN, SSL-VPN, bramy EDR/MDM, appliance’y backupu) — historycznie podatne m.in. na łańcuchy w Fortinet/Ivanti/Citrix, wykorzystywane do inicjalnego foothold.
  3. Zdalny dostęp (RDP/AnyDesk/ScreenConnect) bez MFA lub z wyciekami haseł.
  4. Łańcuch dostaw (konta dostawców SIS/edtech, MDM, zewnętrzni konsultanci).
  5. Shadow IT / błędna konfiguracja — nadmierne uprawnienia, brak Conditional Access, brak segmentacji.

Wskaźniki taktyk (TTP) obserwowane typowo przy atakach na szkoły:

  • Discovery: net group /domain, nltest /dclist, enumeracja Azure AD przez Graph/PowerShell.
  • Lateral movement: SMB/RDP, PSRemoting, lsassy, Impacket (wmiexec.py, smbexec.py), kradzież tokenów OAuth.
  • Persistence: rejestracje aplikacji w Entra ID, dodanie kluczy w HKLM\Software\Microsoft\Windows\CurrentVersion\Run, Scheduled Tasks GPO.
  • Impact: szyfrowanie na serwerach plików i NAS, wyłączenie EDR/AV przez tampering, voice/VoIP DoS i telefonia niedostępna (zbieżne z symptomami MCPS).

Szybkie testy hipotez (blue team) — przykładowe komendy/artefakty:

  • Entra ID – nietypowe logowania i aplikacje: # Ostatnie rejestracje aplikacji (podejrzana persystencja) Get-AzureADApplication -All $true | Sort-Object CreationDate -Descending | Select DisplayName, AppId, CreationDate | Select -First 20 # Nieudane logowania i MFA failures z ostatnich 24h Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) ` -Operations UserLoginFailed,UserLoggedIn | Where-Object {$_.UserId -like "*@mcpsva.org"} | Select CreationDate, UserId, ClientIP, Operation
  • Windows – skoki uprawnień i zdalne wykonywanie: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4672,4624,4673,4688; StartTime=(Get-Date).AddDays(-1)} | Where Message -match 'SeDebugPrivilege|New Logon|Process Name:\s+(?:psexec|wmic|powershell|cmd)' | Select TimeCreated, Id, ProviderName, Message
  • Sieć – skan ruchu lateralnego (SMB/RDP) między strefami: # Ze sniffera w rdzeniu (przykładowo Zeek): zeek -Cr core.pcap local "Site::local_nets += { 10.0.0.0/8 }" # Szukaj anomalii: liczne połączenia 445/TCP i 3389/TCP do wielu hostów w krótkim czasie

Praktyczne konsekwencje / ryzyko

  • Operacyjne: brak łączności i telefonii = utrudniona komunikacja kryzysowa, absencje, transport, opieka nad uczniami ze specjalnymi potrzebami. (W MCPS odnotowano niedostępność telefonów i sieci).
  • Prywatność: szkoły przechowują PII (uczniowie, rodzice, pracownicy). Przy atakach ransomware typowy jest double-extortion (exfiltracja + szyfrowanie).
  • Ryzyko systemowe: powiązania z edtech/SIS/transport/żywienie; możliwe „kaskady” awarii przez konta dostawców.
  • Trend makro: 2024 r. — 116 dotkniętych dystryktów K-12 w USA (Emsisoft). 2025 r. — doniesienia branżowe wskazują utrzymującą się, wysoką presję na oświatę K-12.

Rekomendacje operacyjne / co zrobić teraz

Poniższa lista jest uporządkowana wg priorytetu (T+0h → T+72h). Zaprojektowana z myślą o realiach K-12: ograniczone zasoby, mieszanka on-prem + M365/Google, krytyczne usługi VoIP/SIS.

T + 0–6 h: stabilizacja i komunikacja

  1. Izoluj segmenty z symptomami (VoIP, sieć wewnętrzna, serwery plików). Wymuś network isolation na hostach podejrzanych z poziomu EDR.
  2. „War room” + plan komunikacji (kanały alternatywne: SMS, radio, analogowe linie awaryjne).
  3. Zbierz dowody lotne (listy procesów, tabelę ARP, połączenia sieciowe, tokeny OAuth w M365).
  4. Zaktualizuj baner statusowy na www i social (prosty, faktograficzny, bez spekulacji).

T + 6–24 h: containment techniczny

  1. Reset/MFA dla kont uprzywilejowanych i kont z logowaniami zza granicy.
  2. Wymuś Conditional Access: blokada logowań spoza kraju, „require compliant device”, „block legacy auth”.
  3. Zamknij RDP zewnętrzny, ogranicz VPN do „per-app” i tylko wybranych ról; rozdziel dostęp konsultantów.
  4. Przegląd urządzeń brzegowych (VPN/NGFW/WAF/Ivanti/Citrix) — weryfikacja wersji/popułapek znanych CVE, natychmiastowe patche lub „virtual patching” regułami IPS.
  5. Snapshoty i backup offline systemów krytycznych (SIS, finanse, HR, transport).

T + 24–72 h: eradication i przywracanie

  1. Hunt TTP: nietypowe aplikacje w Entra ID/Google, nowe klucze API, zaufane lokalizacje, rejestracje MFA.
  2. Rotacja sekretów: klucze SSO/SAML, hasła kont usługowych, poświadczenia do NAS/backup.
  3. Przywracanie etapami (najpierw VoIP i łączność, następnie SIS/gradebook; przepuść przez „strefę kwarantanny”).
  4. Edukacja incydentalna: ostrzeż rodziców/pracowników przed phishingiem „na reset hasła” i podszyciami pod szkołę.

Twarde kontrole (konfiguracja):

  • M365/Entra ID (przykład polityki CA — pseudokod): IF user IN "Admins, Staff" THEN Require: MFA (phishing-resistant), Compliant Device, Known Location Block: Legacy Authentication, TOR/Hosting ASN ELSE IF user IN "Vendors" THEN Require: MFA + Device Compliance OR VDIs Restrict: App-Enforced Restrictions, Session Timeout <= 2h
  • Segregacja sieci (SDA/VLAN):
    • Uczniowie ≠ Nauczyciele ≠ Administracja ≠ VoIP ≠ OT (HVAC/kamery).
    • ACL: VoIP ↔ Call Manager only, brak SMB poza strefą serwerową, deny any RDP między stacjami.
  • Backup: 3-2-1, immutability (S3 Object Lock, WORM na NAS), testy odtworzeniowe co najmniej raz/kwartał.
  • E-mail security: post-delivery remediation, link-safe, DMARC p=reject, BEC-rules hunting (forwarding, create-rules).

Gotowce komunikacyjne (szablon dla K-12)

  • Krótki komunikat dla rodzin: „Mieliśmy incydent cyberbezpieczeństwa. Z ostrożności zamykamy szkoły dnia X. Nie ma oznak zagrożenia fizycznego. Pracujemy nad przywróceniem łączności i telefonii. Kolejna aktualizacja o HH:MM.” (Zbieżne z tym, co przekazano w MCPS).

Różnice / porównania z innymi przypadkami

  • MCPS (listopad 2025): wczesna faza, brak potwierdzenia typu malware; główne skutki to telefony i łączność → decyzja o zamknięciu szkół w poniedziałek.
  • MPCS (sierpień 2025): potwierdzony ransomware i potencjalna ekspozycja PII (listy z informacjami o danych objętych ryzykiem). Przypadek innego dystryktu, ale geograficznie bliskiego.

Podsumowanie / kluczowe wnioski

  • MCPS padł ofiarą incydentu, który zakłócił kluczowe usługi IT/telekom — z ostrożności zdecydowano o jednodniowym zamknięciu szkół (10.11). Faktyczny wektor ataku nie został jeszcze ujawniony.
  • Skala zagrożeń dla K-12 utrzymuje się na wysokim poziomie; trend wzrostowy potwierdzają raporty i przeglądy branżowe.
  • Dla dystryktów najważniejsze jest szybkie ograniczenie szkód, twarde kontrole tożsamości i segmentacja, a także przygotowane z wyprzedzeniem szablony komunikacyjne.

Źródła / bibliografia

  1. WJLA (7News): „Manassas City Public Schools close on Monday due to cyberattack” — informacja o zamknięciu szkół, zakłócenia łączności i telefonii, komunikat superintendenta. (WJLA)
  2. FOX5 DC: „Cyberattack closes Manassas City Public Schools on Monday” — list do rodzin z 9 listopada, podkreślenie braku zagrożenia fizycznego. (FOX 5 DC)
  3. WUSA9: „Cybersecurity investigation closes Manassas City Public Schools Monday” — zbieżne informacje o przyczynach zamknięcia i harmonogramie. (wusa9.com)
  4. MCPS — kanał oficjalny (Facebook): komunikat o zamknięciu i działaniach przywracających usługi. (Facebook)
  5. Emsisoft (raport): „The State of Ransomware in the U.S. — 2024” — dane statystyczne nt. liczby zaatakowanych dystryktów K-12. Uzupełniająco: K12 Dive (2025) o częstotliwości ataków w edukacji. (Emsisoft)

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”