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.
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):
Phishing / BEC → uzyskanie poświadczeń do M365/Google Workspace; pivot przez VPN/SSO.
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.
Zdalny dostęp (RDP/AnyDesk/ScreenConnect) bez MFA lub z wyciekami haseł.
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
Izoluj segmenty z symptomami (VoIP, sieć wewnętrzna, serwery plików). Wymuś network isolation na hostach podejrzanych z poziomu EDR.
„War room” + plan komunikacji (kanały alternatywne: SMS, radio, analogowe linie awaryjne).
Zbierz dowody lotne (listy procesów, tabelę ARP, połączenia sieciowe, tokeny OAuth w M365).
Zaktualizuj baner statusowy na www i social (prosty, faktograficzny, bez spekulacji).
T + 6–24 h: containment techniczny
Reset/MFA dla kont uprzywilejowanych i kont z logowaniami zza granicy.
Zamknij RDP zewnętrzny, ogranicz VPN do „per-app” i tylko wybranych ról; rozdziel dostęp konsultantów.
Przegląd urządzeń brzegowych (VPN/NGFW/WAF/Ivanti/Citrix) — weryfikacja wersji/popułapek znanych CVE, natychmiastowe patche lub „virtual patching” regułami IPS.
Snapshoty i backup offline systemów krytycznych (SIS, finanse, HR, transport).
T + 24–72 h: eradication i przywracanie
Hunt TTP: nietypowe aplikacje w Entra ID/Google, nowe klucze API, zaufane lokalizacje, rejestracje MFA.
Rotacja sekretów: klucze SSO/SAML, hasła kont usługowych, poświadczenia do NAS/backup.
Przywracanie etapami (najpierw VoIP i łączność, następnie SIS/gradebook; przepuść przez „strefę kwarantanny”).
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ł.
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
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)
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)
WUSA9: „Cybersecurity investigation closes Manassas City Public Schools Monday” — zbieżne informacje o przyczynach zamknięcia i harmonogramie. (wusa9.com)
MCPS — kanał oficjalny (Facebook): komunikat o zamknięciu i działaniach przywracających usługi. (Facebook)
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)
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
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.
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).
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ń.
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
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.
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.
Twarde higiena kont
Przeglądy sesji Google (Security Checkup): wylogowanie ze wszystkich urządzeń, rotacja haseł, przegląd autoryzowanych aplikacji OAuth.
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
The Korea Times – “N. Korea-backed hackers deploy new malware-led cyberattack: report” (Nov 10, 2025). (The Korea Times)
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ło
ID / typ
Co obserwować
Wskazówki
Windows Security
4688 (Process Create)
java.exe/javaw.exe/javaws.exe jako dziecko chrome.exe/msedge.exe/firefox.exe/iexplore.exe
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.
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
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"
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.
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.
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)
Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
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
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
BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
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)
Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)
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.
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:
Publikacja pluginu w Marketplace jako zwykłego rozszerzenia VS Code; opis nie krył funkcji „zip-upload-encrypt”.
Automatyczna aktywacja (activation events „onStartupFinished”/„*”) – uruchomienie funkcji zipUploadAndEncrypt już przy instalacji/otwarciu edytora.
Zbieranie danych – tworzenie archiwum ZIP wskazanego katalogu (np. C:\Users\Public\testing lub /tmp/testing w PoC).
Eksfiltracja – wysyłka na zdalny serwer/C2; w tym przypadku GitHub (repo prywatne) jako boczny kanał poleceń (polling commitów).
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
Zaufanie do Marketplace ≠ bezpieczeństwo. Moderacja nie zastąpi kontroli organizacyjnej (allow-lista, mirror, polityki).
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.
Operationalize security w DevEx: inwentaryzacja rozszerzeń, EDR-hunting wokół VS Code i blokady sieciowe to dziś „must-have”.
Przygotuj IR pod developerów: procedury odtwarzania stanowisk i rotacji sekretów po incydencie z IDE.
Źródła / bibliografia
Dark Reading – opis incydentu, cytat Microsoftu, szczegóły publikacji i usunięcia rozszerzenia. (Dark Reading)