Archiwa: Malware - Strona 145 z 165

Złośliwe rozszerzenia w VSCode Marketplace ukrywały trojana w fałszywym pliku PNG

Wprowadzenie do problemu / definicja luki

Badacze ReversingLabs opisali kampanię, w której 19 rozszerzeń VS Code publikowanych w oficjalnym VSCode Marketplace zawierało złośliwy ładunek ukryty w folderze node_modules. Najbardziej charakterystyczny element ataku: plik banner.png, który nie był obrazem, lecz archiwum z dwoma binariami — wykorzystywany był cmstp.exe (Living-off-the-Land) oraz trojan napisany w Rust. Kampania miała działać od lutego 2025 r., a znaleziska zgłoszono do Microsoftu na początku grudnia; rozszerzenia zostały usunięte z marketplace.

W skrócie

19 złośliwych rozszerzeń (głównie „theme’y”) dostarczało zmodyfikowane zależności w node_modules, aby ominąć pobieranie z npm i ukryć różnice.
Atak modyfikował popularny pakiet path-is-absolute (ponad 9 mld pobrań) lub alternatywnie @actions/io, dorzucając klasę inicjującą dropper.
Dropper dekodował zaszyfrowany JavaScript z pliku lock (base64 + odwrócenie łańcucha), następnie uruchamiał binaria z fałszywego banner.png przez cmstp.exe, co finalnie ładowało trojana w Rust.
Microsoft usunął zgłoszone pozycje z Marketplace; użytkownicy powinni sprawdzić system pod kątem kompromitacji.

Kontekst / historia / powiązania

Marketplace’y dla IDE stały się atrakcyjnym wektorem łańcucha dostaw. W 2025 r. obserwowano kolejne incydenty z udziałem złośliwych rozszerzeń VS Code oraz pakietów Go/npm/Rust kradnących dane devów. Równolegle badania Wiz wykazały setki wycieków sekretów i tokenów publikacyjnych w pakietach rozszerzeń (co umożliwia skryte „pchanie” aktualizacji do całej bazy instalacyjnej). Te trendy pokazują, że nawet „niewinne” motywy/tematy mogą być nośnikiem ryzyka supply-chain.

Analiza techniczna / szczegóły luki

Pakowanie zależności w rozszerzeniach VS Code. W przeciwieństwie do typowego obiegu npm (gdzie npm install pobiera świeże zależności), rozszerzenia VS Code dostarczają kompletny folder node_modules w paczce .vsix. To pozwala atakującym „podmienić” treść popularnych paczek tylko na potrzeby swojego rozszerzenia — bez modyfikowania artefaktów na npm i bez czerwonych flag po stronie użytkownika.

Modyfikacja dependency. Atakujący dodali nową klasę do index.js w path-is-absolute (lub w części próbek użyli @actions/io), która automatycznie uruchamiała się przy starcie VS Code i dekodowała obfuskowany dropper z pliku lock (base64 + reverse).

Fałszywy obraz banner.png. W większości wariantów w node_modules znajdował się banner.png — w praktyce archiwum z dwoma binariami: cmstp.exe (LOLBin) do uruchomienia ładunku oraz docelowym trojanem Rust. W wersjach z @actions/io pliki były ukryte w parach .ts/.map. Zdolności trojana są nadal analizowane, ale łańcuch wykonywania jest spójny między próbkami.

Przykładowe nazwy rozszerzeń (IOC): m.in. Malkolm Theme, PandaExpress Theme, Prada 555 Theme, Priskinski Theme — wszystkie w wersji 1.0.0; ReversingLabs opublikował pełną listę nazw/SHA1.

Praktyczne konsekwencje / ryzyko

Ryzyko supply-chain po stronie devów. Wystarczy instalacja „tematu”/„motywu”, by kod w node_modules uruchomił dropper podczas startu VS Code. W środowisku developerskim to często maszyny z tajemnicami (tokeny, SSH, ciasteczka przeglądarek, konfiguracje chmurowe).
Trudność detekcji. Zależności są „zaufane z nazwy”, a plik PNG nie otwiera się jako obraz — nie generuje to oczywistych alertów. LOLBin cmstp.exe zaciera ślady.
Szybka dystrybucja / aktualizacje. Auto-update rozszerzeń i (osobny problem) wyciekające PAT-y wydawców zwiększają zasięg i prędkość potencjalnego skażenia.

Rekomendacje operacyjne / co zrobić teraz

1) Triage i hunting (Windows/macOS):

Inwentaryzacja VS Code: code --list-extensions --show-versions i weryfikacja na liście IOC ReversingLabs. Usuń podejrzane rozszerzenia, zwłaszcza o nazwach z rodziny Malkolm/PandaExpress/Prada 555/Priskinski (v1.0.0).
Przegląd paczek .vsix: rozpakuj (ZIP) i zbadaj node_modules pod kątem zmodyfikowanego index.js w path-is-absolute/@actions/io, obecności plików lock, fałszywych .png, nietypowych .ts/.map z binariami.
Telemetria / EDR: poluj na uruchomienia cmstp.exe przez procesy VS Code (Code.exe, code), nietypowe wywołania curl/PowerShell oraz świeże binaria Rust w katalogach rozszerzeń.

2) Odtwarzanie zaufania:

Reset sekretów na stacjach dev (tokeny API, PAT, klucze chmurowe, cookies przeglądarek) jeżeli wykryto instalację z listy IOC. Zalecana rotacja haseł i odświeżenie sesji przeglądarek. (Kontekst: znane kampanie kradły cookies, Wi-Fi i zrzuty ekranu).
Segregacja środowisk: minimalizuj pracę z wrażliwymi sekretami na stacjach z bogatym zestawem rozszerzeń VS Code.

3) Hardening procesowy:

Allowlista rozszerzeń i centralna polityka dla VS Code (np. przez Settings Sync for Business, polityki systemowe, MDM). Ogranicz auto-update dla rozszerzeń wysokiego ryzyka lub wymuś update’y z repozytorium wewnętrznego po skanowaniu.
Skanowanie rozszerzeń przed dystrybucją (CI) — rozpakowanie .vsix, statyczna analiza node_modules, reguły na anomalie (np. binaria w PNG, obecność cmstp.exe).
Program „least extensions”: ogranicz liczbę instalowanych pluginów; weryfikuj reputację wydawcy, historię wersji, liczbę pobrań i recenzje.

4) Kontrole platformowe (dla zespołów platform/devx):

Repo lokalne rozszerzeń (mirror/allowlist) zamiast bezpośredniego Marketplace.
Sekrety w pakietach: przegląd publikowanych przez organizację rozszerzeń pod kątem wycieków PAT/API i zaciśnięcie polityk TTL dla tokenów (wnioski z badań Wiz).

Różnice / porównania z innymi przypadkami (2025)

GlassWorm / WhiteCobra i inne fale — wcześniejsze kampanie celowały w VS Code/Open VSX, dostarczając m.in. infostealery (kradzież ciasteczek, sesji, portfeli). Opisywany dziś przypadek wyróżnia się „fałszywym PNG” i nadużyciem pre-pakowanych zależności w node_modules, zamiast prostego pobrania payloadu po instalacji.
„Material Icon Theme” – Rust implants — niedawna analiza Nextron wykazała wykorzystanie implantów Rust i nietypowych kanałów C2 (Solana/Google Calendar). To inna kampania, ale trend wykorzystania Rust + sprytnych nośników się utrzymuje.

Podsumowanie / kluczowe wnioski

Atakujący schowali malware w zaufanych nazwach zależności i w „obrazku” PNG, co świetnie wpisuje się w model niskiej widoczności w IDE.
Audyt rozszerzeń musi obejmować folder node_modules. Samo zerknięcie w package.json to za mało.
Organizacje powinny centralizować kontrolę nad rozszerzeniami, rotować sekrety po incydentach i polować na LOLBiny odpalane przez VS Code.

Źródła / bibliografia

ReversingLabs: „VS Code extensions use fake image containing a trojan” (pełne IOC, szczegóły techniczne). (ReversingLabs)
BleepingComputer: „Malicious VSCode Marketplace extensions hid trojan in fake PNG file” (daty, usunięcie z Marketplace). (BleepingComputer)
The Hacker News: „Researchers Find Malicious VS Code, Go, npm, and Rust Packages…” (szerszy kontekst kradzieży danych przez rozszerzenia/pakiety). (The Hacker News)
Wiz Research: „Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (ryzyko tokenów wydawców, rekomendacje hardeningu). (wiz.io)
Nextron Systems: „Analysis of the Rust implants found in the malicious VS Code extension” (porównawczo: Rust C2/implanty). (nextron-systems.com)

React2Shell: fala ataków z dostarczaniem koparek, backdoorów i implantów. Co muszą wiedzieć zespoły bezpieczeństwa?

Wprowadzenie do problemu / definicja luki

React2Shell (CVE-2025-55182) to krytyczna (CVSS 10.0) luka RCE w React Server Components (RSC), umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia za pomocą specjalnie spreparowanych żądań HTTP. Dotyka ekosystemu React 19 i frameworków korzystających z RSC (m.in. Next.js, React Router, Waku, RedwoodSDK). Producent wydał poprawki dla React 19.0.1/19.1.2/19.2.1.

W skrócie

Eksploatacja trwa na szeroką skalę – pierwsze ataki odnotowano niemal natychmiast po ujawnieniu. W katalogu CISA KEV luka widnieje jako aktywnie wykorzystywana, a termin remediacji dla agencji federalnych przyspieszono do 12 grudnia 2025 r.
Łańcuchy ataku są zróżnicowane: kryptokoparki, backdoory Linuksa (np. BPFDoor, PeerBlight), tunele (CowTunnel), implanty post-eksploatacyjne (ZinFoq, Sliver), webshelle i narzędzia C2 (Cobalt Strike).
Aktorzy: aktywność powiązana z grupami z Chin (IAB i operatorzy botnetów) oraz ślady TTP zbieżne z kampaniami DPRK (m.in. wątki EtherRAT/EtherHiding).

Kontekst / historia / powiązania

Skala ekspozycji jest wysoka – React i Next.js są powszechnie wdrażane w środowiskach enterprise. Shadowserver raportował wzrost z ~77 tys. do >165 tys. adresów IP i setek tysięcy domen z podatnym kodem. Jednocześnie AWS i inni dostawcy obserwowali gwałtowne przyspieszenie ataków po publikacji PoC i wskazują, że operatorzy z Chin byli wśród pierwszych, którzy rozpoczęli eksploatację.

Analiza techniczna / szczegóły luki

Rdzeniem błędu jest niebezpieczna deserializacja w implementacji protokołu Flight wykorzystywanego przez RSC. W praktyce wystarczy sfałszowane żądanie HTTP (często POST) z „ładunkiem” RSC, aby doprowadzić do wykonania uprzywilejowanego kodu JS po stronie serwera. Luka jest niska-złożona, bez interakcji użytkownika, a skuteczność exploitów w testach zbliża się do 100%. W podatności uczestniczą m.in. pakiety react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack w wersjach 19.0/19.1/19.2.

Istotny niuans: nawet jeśli aplikacja nie używa jawnie Server Functions, ale wspiera RSC, wciąż może być atakowalna. Wiele domyślnych konfiguracji (np. świeży Next.js „create-next-app”) jest podatnych bez zmian w kodzie.

Praktyczne konsekwencje / ryzyko

Dostawcy wykryli bogaty wachlarz ładunków po udanej eksploatacji:

Kryptokoparki (masowe próby monetyzacji zasobów kontenerów/K8s).
Kradzież poświadczeń chmurowych (AWS/Git/CI), następnie ruch boczny w chmurze.
Backdoory Linuksa: m.in. BPFDoor (wcześniej łączony z Red Menshen/Earth Bluecrow), PeerBlight (nowy, opisany przez Huntress).
Tunele/reverse proxy: CowTunnel; implanty: ZinFoq, SNOWLIGHT, VShell; narzędzia C2: Cobalt Strike, Sliver; webshelle udające manager plików React.

Dodatkowo, Palo Alto/Unit 42 opisuje żywiołowe „rekonesanse po wejściu” oparte na prostych skryptach bash/Base64 (uname/id/hosts/resolv.conf) i szybkie pobieranie payloadów via curl/wget. To ułatwia automatyzację kampanii masowych i podszywanie się pod skany.

Rekomendacje operacyjne / co zrobić teraz

Patch & hardening (priorytet 0):

Zaktualizuj React do 19.0.1 / 19.1.2 / 19.2.1 oraz odpowiednie wersje Next.js zgodnie z tabelą Unit 42. Zrób to w środowiskach prod/stage/dev; zrób rebuild i redeploy.
Jeśli nie możesz patchować natychmiast, zablokuj/ogranicz dostęp do punktów RSC (WAF/NGFW, allowlisty, blokada metod/ścieżek) i segmentuj workloady. (Unit 42/Wiz potwierdzają, że ataki często celują w Next.js i kontenery/Kubernetes).

Detekcje i myślenie TTP:

Szukaj anomalii HTTP do endpointów RSC (nienaturalne payloady, wysyp błędów deserializacji).
Telemetria procesów/sieci: curl/wget uruchamiane przez procesy aplikacyjne, łańcuchy bash -c z base64, nietypowe wywołania powłok z katalogów aplikacji.
Artefakty poeksploatacyjne: droppery (np. sex.sh), webshelle „React File Manager”, wskaźniki C2 znane z kampanii (np. Sliver/Cobalt Strike beacony).
Malware/implanty: sygnatury/IOCe dla BPFDoor, NoodleRAT, PeerBlight, CowTunnel, ZinFoq, SNOWLIGHT/VShell; oraz koparek/kube-miners. (Huntress/Unit 42/SecurityWeek).

IR & chmura:

Rotacja secrets (AWS/GCP/Azure), tokenów CI/CD, kluczy SSH wykorzystywanych przez aplikacje RSC.
Przegląd Kubernetes: DaemonSety podejrzanych koparek, nieautoryzowane CronJoby, pods z eskalowanymi uprawnieniami. (Wiz obserwuje nacisk na workloady kontenerowe).

Zgodność i wymogi:

Traktuj CVE-2025-55182 jako KEV – jeśli podlegasz wytycznym CISA, respektuj deadline 12 grudnia 2025 r.

Różnice / porównania z innymi przypadkami

W odróżnieniu od klasycznych fal kryptokoparek w Node/Express, tutaj atakujący mają „wejście” na poziomie RSC/Flight, co omija część typowych filtrów i uderza w warstwę SSR. Z drugiej strony spektrum widać też kampanie IAB (initial access broker) – szybkie „otwarcie drzwi”, zrzut poświadczeń chmurowych i sprzedaż dostępu dalej (SNOWLIGHT/VShell). Jednocześnie pojawia się nowe malware (PeerBlight/CowTunnel/ZinFoq), co sugeruje, że React2Shell stał się testową rampą dla świeżych narzędzi ofensywnych.

Podsumowanie / kluczowe wnioski

Reaguj jak na incydent 0-day/KEV – patch, izolacja ekspozycji RSC, wzmożona telemetria.
Nie lekceważ „commodity”: koparki często są pierwszym śladem, ale w tle bywa IAB/C2 i długoterminowe osadzenie.
Chmura i K8s to dziś główny wektor monetizacji i pivotu – ustaw priorytety monitoringu właśnie tam.

Źródła / bibliografia

SecurityWeek – przegląd kampanii, typy malware, statystyki Shadowserver, KEV/terminy CISA: „Wide Range of Malware Delivered in React2Shell Attacks” (11 grudnia 2025). (SecurityWeek)
Unit 42 (Palo Alto Networks) – analiza techniczna, TTP, lista obserwowanych implantów i wersje łatek: „Exploitation of Critical Vulnerability in React Server Components” (akt. 10 grudnia 2025). (Unit 42)
Huntress – szczegóły nowych rodzin (PeerBlight, CowTunnel, ZinFoq) i łańcuchów dystrybucji: „PeerBlight Linux Backdoor Exploits React2Shell”. (Huntress)
Wiz – nacisk ataków na Next.js/Kubernetes, kradzież sekretów i Sliver: „React2Shell Deep Dive: CVE-2025-55182 Exploit Mechanics”. (wiz.io)
CISA KEV – status „exploited in the wild” i wymogi remediacji: Known Exploited Vulnerabilities Catalog. (CISA)

Ekspert To Rola Nadawana Przez Innych – Nie Liczba Lat W CV

Dlaczego piszę o tym jako pierwszy — i co to znaczy być ekspertem

Zgodnie ze słownikiem, ekspert to „osoba mająca gruntowną wiedzę w jakiejś dziedzinie”. Innymi słowy, to ktoś o głębokich kompetencjach, często w wąskiej specjalizacji, komu przypisuje się autorytet w danym zakresie. Kluczowe jest tu właśnie przypisanie – rola eksperta wynika z uznania przez innych ludzi. Nie wystarczy wpisać sobie wielu lat doświadczenia w CV. W branży technologicznej, a zwłaszcza w cyberbezpieczeństwie, można mieć dekadę stażu i wciąż nie być postrzeganym jako ekspert, albo odwrotnie – już po kilku latach intensywnej pracy zyskać opinię eksperta w konkretnym obszarze.

Czytaj dalej

DroidLock: nowe oprogramowanie wymuszające dla Androida blokuje urządzenia i żąda okupu

Wprowadzenie do problemu / definicja luki

10–11 grudnia 2025 r. badacze Zimperium opisali nową kampanię złośliwego oprogramowania na Androida o nazwie DroidLock. Malware blokuje ekran, wymusza kontakt e-mailowy i grozi zniszczeniem danych w 24 godziny, a dodatkowo umożliwia atakującemu niemal pełne przejęcie urządzenia (zdalne sterowanie, zmiana PIN/biometrii, wipe). Celem są głównie użytkownicy hiszpańskojęzyczni, a dystrybucja odbywa się przez fałszywe strony i aplikacje podszywające się m.in. pod operatorów telekomunikacyjnych.

W skrócie

Typ zagrożenia: ransomware-locker (bez szyfrowania plików, z blokadą dostępu + groźbą zniszczenia danych).
Wejście: phishing stron/apek, dropper → drugi etap z właściwym payloadem.
Uprawnienia: nadużycie Accessibility Services i Device Administrator do przejęcia kontroli (lock/wipe/zmiana PIN).
Zdalne sterowanie: kanały HTTP/WebSocket, VNC (sharing/stream ekranu).
Celowana kampania: użytkownicy hiszpańskojęzyczni (Hiszpania).
Wykrywanie: Zimperium zgłasza próbki w ramach App Defense Alliance; Play Protect ma blokować znane warianty.

Kontekst / historia / powiązania

„Lockery” na Androida pojawiają się od lat (np. Android/Locker, DoubleLocker). Klasyczne taktyki to pełnoekranowe nakładki, wymuszenia quasi-policyjne oraz nadużycia Device Admin/Accessibility – dokładnie te elementy widzimy w DroidLock. Historyczne analizy ESET opisują, jak twórcy mobilnego ransomware’u od lat korzystają z tych mechanizmów i jak w 2017–2018 r. zaczęli masowo nadużywać Accessibility do automatycznego nadawania sobie uprawnień.

Analiza techniczna / szczegóły luki

Łańcuch infekcji. Użytkownik trafia na phishingową stronę i pobiera dropper, który dosyła właściwy moduł (drugi etap). Po instalacji malware żąda Accessibility i Device Admin, a gdy ofiara je nada, samo „klika” kolejne zgody, aby uzyskać dostęp do SMS-ów, kontaktów, logów połączeń, audio itp.

Komunikacja i C2. DroidLock ustanawia połączenia HTTP (telemetria) i WebSocket (komendy w czasie rzeczywistym). Obsługuje 15 komend, m.in.: RANSOMWARE (nakładka żądania okupu), BLACK_SCREEN / UPDATE_OVERLAY (fałszywy ekran aktualizacji blokujący interakcje), BLOCK_BIOMETRIC (blokada urządzenia), WIPE (factory reset), MUTE, CAMERA, VNC (zdalne sterowanie), INJECT_APP (nakładki credential harvesting), APP_BLOCK_LOCK_PATTERN (kradzież wzoru blokady), UNINSTALL_APP.

Nakładki i kradzież wzoru blokady. Malware wstrzykuje WebView/HTML nad wybranymi aplikacjami albo wyświetla szybki „lock-pattern overlay” z zasobów APK, by przejąć wzór odblokowania i ułatwić późniejsze sterowanie VNC.

Ransom-overlay i wymuszenie. Po komendzie z C2 wyświetla się pełnoekranowy ekran z instrukcją kontaktu (adres Proton) i ultimatum 24 h. DroidLock nie szyfruje plików, ale łączy blokadę urządzenia z groźbą skasowania danych – co skutecznie wymusza okup.

MITRE ATT&CK (Mobile) – przykłady mapowania:

T1660 Phishing (dystrybucja przez strony/apki)
T1626.001 Abuse Elevation Control (Device Admin)
T1629.002 Device Lockout
T1516/T1417 Input Injection/Keylogging (sterowanie/zbieranie danych)
T1517 Access Notifications (przechwyt OTP)
T1414 Clipboard Data (wyciek schowka)
Zimperium wskazuje te techniki wprost w raporcie.

Praktyczne konsekwencje / ryzyko

Utrata dostępu do telefonu (zmiana PIN/biometrii, lockout) i ryzyko utraty danych (wipe).
Kompromitacja kont: przejęcie OTP z powiadomień, keylogging/overlay nad bankowością i komunikatorami.
Ryzyko dla firm: urządzenie staje się „wrogim punktem końcowym” wewnątrz sieci (VNC, screen recording, sterowanie UI).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (BYOD/indywidualni):

Nie instaluj APK spoza Google Play; jeżeli musisz – tylko od sprawdzonych wydawców. Włącz i nie wyłączaj Google Play Protect.
Zachowaj nieufność wobec żądań Accessibility/Device Admin – szczególnie gdy pojawiają się od razu po instalacji.
Jeśli już jesteś zainfekowany/a:
- Spróbuj uruchomić telefon w Trybie awaryjnym (Safe Mode) i odinstalować podejrzaną apkę; Safe Mode blokuje aplikacje firm trzecich, co często „zdejmuje” nakładkę.
- Jeśli nie możesz cofnąć uprawnień Device Admin lub usunąć aplikacji – rozważ przywrócenie ustawień fabrycznych z kopii zapasowej (ostatnia deska ratunku). (Wipe jest też wykorzystywany przez sam malware).
Kopie zapasowe (foto/dokumenty) w chmurze/szyfrowane lokalnie – minimalizują presję okupu. (Wnioski ogólne z badań ESET).

Dla organizacji:

MTD/EDR na mobile + runtime behavioral detection (np. wykrywanie nadużyć Accessibility/Admin, overlay, VNC/screen-recording).
Polityki MDM/UEM: blokuj sideloading, wymagaj sklepów zarządzanych, ogranicz uprawnienia Accessibility, wymuś regularne aktualizacje i skanowanie urządzeń. (Dobre praktyki zgodne z rekomendacjami branżowymi).
Szkolenia phishingowe dla mobile i monitoring anomalii (np. nagłe wyciszenie urządzeń, nagłe żądania admin perms).

Różnice / porównania z innymi przypadkami

Bez szyfrowania plików, ale z pełnym przejęciem – DroidLock eskaluje w stronę totalnego sterowania (VNC, screen streaming), co rzadziej występowało w starszych lockerach, które skupiały się na nakładkach/pseudo-policyjnych żądaniach.
Nowoczesne nadużycia Accessibility + automatyzacja zgód – trend obserwowany od DoubleLocker, lecz tu rozszerzony o bogaty zestaw komend C2.

Podsumowanie / kluczowe wnioski

DroidLock to świeża kampania locker-ransomware na Androida, która nie szyfruje danych, ale łączy blokadę urządzenia, groźbę kasowania i zdalne sterowanie do skutecznego wymuszenia. Najskuteczniejszą ochroną jest niewłączanie sideloadingu, odmowa podejrzanych uprawnień, aktywne Play Protect oraz MTD/MDM w firmach. W razie infekcji – Safe Mode i deinstalacja często wystarczą; gdy to niemożliwe, przywrócenie fabryczne z kopii zapasowej.

Źródła / bibliografia

Zimperium (raport techniczny, 10 grudnia 2025): „Total Takeover: DroidLock Hijacks Your Device”. (zimperium.com)
BleepingComputer (news, 10 grudnia 2025): „New DroidLock malware locks Android devices and demands a ransom”. (BleepingComputer)
SiliconANGLE (news/omówienie, 10 grudnia 2025): „New DroidLock threat gives attackers near-total control of Android phones”. (SiliconANGLE)
Trend Micro (poradnik, 27 października 2025): „Removing lock-screen type ransomware using Safe Mode on Android device”. (Trend Micro Success)
ESET (whitepaper): „Android Ransomware: From Android Defender to DoubleLocker” – kontekst historyczny i taktyki (Device Admin, Accessibility).

„Spiderman” – nowy phishing-as-a-service na celowniku europejskich banków

Wprowadzenie do problemu / definicja luki

Na podziemnych rynkach pojawił się nowy phishing kit o nazwie „Spiderman”, który umożliwia przestępcom szybkie uruchamianie kampanii podszywających się pod dziesiątki europejskich banków, fintechy (np. Klarna, PayPal) oraz portfele kryptowalut (Ledger, MetaMask, Exodus). Zestaw generuje pikselowe klony stron logowania, gromadzi hasła, kody 2FA/OTP, a nawet dane kart płatniczych – i to w czasie rzeczywistym dzięki panelowi operatorskiemu. Badacze z Varonis wskazują też popularność narzędzia (grupa na Signal ~750 członków), co sugeruje aktywne wykorzystanie na szeroką skalę.

W skrócie

Zakres: banki w min. pięciu krajach UE (m.in. Deutsche Bank, ING, Comdirect, Volksbank, Commerzbank, CaixaBank), wybrane usługi fintech i krypto.
Funkcje: real-time podgląd sesji ofiary, przechwytywanie OTP/PhotoTAN, pełne formularze KYC/kartowe, eksport danych 1-kliknięciem, filtrowanie geo/ISP/urządzeń, przekierowania „niepożądanych” wizyt.
Model: gotowy framework PhaaS, obniżający wymagane umiejętności do „kilku klików”, co zwiększa skalę i tempo ataków.

Kontekst / historia / powiązania

Zestawy Phishing-as-a-Service (PhaaS) od lat demokratyzują oszustwa, jednak „Spiderman” wyróżnia się konsolidacją wielu marek bankowych w jednym interfejsie oraz naciskiem na przechwytywanie OTP. Trend automatyzacji i „klikowego” klonowania portali finansowych jest szeroko opisywany w najnowszych analizach branżowych.

Analiza techniczna / szczegóły luki

Architektura i panel operatorski

Panel wyświetla na żywo sesje ofiar (login → kolejne kroki weryfikacji), pozwala wyzwalać dodatkowe żądania (np. prośba o PhotoTAN, numer karty, dane osobowe), oznaczać sesje jako „zakończone” i eksportować zebrane rekordy.
Modułowość: nowe banki, portale i metody uwierzytelniania można dokładać w formie modułów, co przyspiesza adaptację do zmian w e-bankowości.

Klonowanie i zbieranie danych

Mechanizm „Index This Bank” automatycznie przygotowuje klon strony logowania + widoki 2FA/PhotoTAN i formularze kartowe. Dane (login/hasło, PII, numer telefonu, karta, metadane UA/IP) są przekazywane do panelu w czasie rzeczywistym.

Omijanie zabezpieczeń i ukrywanie się

Geo-whitelisting, whitelisty ISP/ASN, filtrowanie urządzeń (desktop/mobile/Android/iOS) oraz customowe przekierowania ograniczają widoczność kampanii w crawlerach i narzędziach TI. To utrudnia wykrycie i analizę automatyczną.

2FA w Europie: PhotoTAN

„Spiderman” obsługuje PhotoTAN – mozaikowy obraz skanowany aplikacją bankową, generujący OTP specyficzny dla transakcji. Przechwytywanie PhotoTAN/OTP w czasie rzeczywistym sprawia, że same loginy nie wystarczą do ochrony kont.

Praktyczne konsekwencje / ryzyko

Przejęcie kont bankowych (ATO) i fraud transakcyjny – atakujący posiadają komplet: poświadczenia + OTP + dane karty.
SIM-swapping / kradzież tożsamości – pełne pakiety PII ułatwiają dalsze nadużycia (kredyty, subskrypcje, wyłudzenia).
Multi-platformowy wektor – jednoczesne uderzenia w bankowość i krypto zwiększają skalę szkód.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team (banki, fintechy)

Zasilcie detekcję o wskaźniki kampanii PhaaS: korelacje krótkotrwałych klonów domen, certyfikatów DV, hostingu w ASN-ach „residential proxy” i nietypowych łańcuchach przekierowań (przynęta → filtr → klon).
WAF/EDR + threat intel: reguły na zachowania strony logowania (np. nietypowe pola/żądania PhotoTAN poza standardowym flow), rozpoznawanie fingerprinting JS i anti-bot typowych dla kitów.
Telemetryka 2FA: alertuj niespójności – OTP/PhotoTAN żądany bez akcji użytkownika; wiele żądań OTP w krótkim czasie; logowanie i autoryzacja z różnych AS/urz. w obrębie jednej sesji. (Wskazany przez Varonis real-time model ataku.)
Brand protection/Takedown: szybkie seeding i zgłaszanie nowych klonów, automatyczne crawler-y z residential vantage points (obejście geo/ASN filtrów stosowanych przez kit).
Transakcyjne „risk-based auth”: silniejsze reguły dla receiver novelty (nowy odbiorca), amount anomaly, wymuszony out-of-band potwierdzeń (push z opisem transakcji, nie tylko kod).

Dla działów biznesu/bezpieczeństwa klienta

UX komunikatów: w aplikacji i WWW wyświetlaj ostrzeżenia kontekstowe o trwających kampaniach (np. „Uwaga: nie podawaj kodu PhotoTAN, jeśli to nie Twoja akcja”).
Aktywne edukacje: krótkie, cykliczne in-app bannery i SMS-y o phishingu na markę – zwłaszcza przy wzmożonej aktywności PhaaS. BleepingComputer podkreśla, że kliknięcie linku do fałszywej domeny jest wciąż warunkiem powodzenia ataku.

Dla użytkowników (polskich i UE)

Sprawdzaj domenę przed logowaniem i unikaj linków z SMS/e-mail prowadzących „na skróty”.
Nie podawaj PhotoTAN/OTP, jeśli nie inicjowałeś logowania/operacji — to silny sygnał przejęcia.
Używaj aplikacji bankowej do wchodzenia na konto (głębokie linki oficjalne), a nie linków z wiadomości.
Zgłaszaj podejrzane strony bankowi; w razie wątpliwości zablokuj kartę i zmień hasło.

Różnice / porównania z innymi przypadkami

W porównaniu z typowymi kitami „single-brand”, „Spiderman” konsoliduje dziesiątki marek i krajów w jednym panelu, co znacząco podnosi efektywność i rotację kampanii.
Na tle wcześniejszych fal oszustw bankowych w Europie, gdzie 2FA omijano głównie przez malware w przeglądarce/na telefonie, tutaj kluczowe jest interaktywne przechwytywanie OTP/PhotoTAN w czystym phishingu (bez infekowania urządzeń). Dziennikarskie relacje branżowe potwierdzają „klikowe” klonowanie i real-time kradzież OTP.

Podsumowanie / kluczowe wnioski

„Spiderman” to zaawansowany PhaaS przystosowany do realiów europejskiej bankowości: obsługa PhotoTAN/OTP, szerokie targetowanie wielomarkowe, anty-analiza (geo/ISP/device), a do tego niski próg wejścia dla napastników. W praktyce oznacza to wzrost wolumenu i skuteczności kampanii podszywania się pod banki oraz większe ryzyko ATO i fraudu. Organizacje finansowe powinny priorytetowo wzmocnić detekcję na poziomie zachowań sesji i 2FA, a klienci – unikać linków i nie autoryzować niczego, czego sami nie zainicjowali.

Źródła / bibliografia

B. Toulas, BleepingComputer: New Spiderman phishing service targets dozens of European banks (10 grudnia 2025). (BleepingComputer)
Varonis Threat Labs: Spiderman Phishing Kit Mimics Top European Banks With A Few Clicks (9 grudnia 2025, aktualizacja). (Varonis)
eSecurityPlanet: Spiderman phishing kit lets attackers clone European banks in seconds (10 grudnia 2025). (eSecurity Planet)
(Dodatkowe tło) Zestawienie wpisów Varonis – sekcja Threat Research. (Varonis)

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

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.).
Przejrzyj skrypty: wszędzie tam, gdzie wywołujesz Invoke-WebRequest w PowerShell 5.1, dodaj -UseBasicParsing dla zadań automatycznych / bezinteraktywnych.
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.)
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.
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

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

CISA dodaje dwie luki do katalogu KEV: Windows Cloud Files Mini Filter (CVE-2025-62221) i WinRAR Path Traversal (CVE-2025-6218)

Wprowadzenie do problemu / definicja luk

9 grudnia 2025 r. CISA dodała dwie nowe pozycje do katalogu Known Exploited Vulnerabilities (KEV) na podstawie dowodów aktywnej eksploatacji w środowiskach produkcyjnych. Są to:

CVE-2025-62221 – Windows Cloud Files Mini Filter: błąd use-after-free prowadzący do eskalacji uprawnień (EoP) do SYSTEM. Pozycja otrzymała w KEV datę dodania 2025-12-09 i termin na wdrożenie poprawek 2025-12-30.
CVE-2025-6218 – WinRAR Path Traversal: podatność path traversal umożliwiająca RCE przy interakcji użytkownika (otwarcie spreparowanego archiwum/odwiedzenie strony). Również dodana 2025-12-09 z terminem 2025-12-30.

W skrócie

Status: obie luki są aktywnie wykorzystywane → priorytet krytyczny w zarządzaniu podatnościami.
Wpływ:
- CVE-2025-62221 – lokalna EoP do SYSTEM po zdobyciu wstępnego dostępu; wykorzystywana w 0-day wg przeglądów Patch Tuesday.
- CVE-2025-6218 – zdalne RCE na koncie bieżącego użytkownika po otwarciu złośliwego archiwum.
Działania CISA (BOD 22-01): wymagane zastosowanie poprawek/łagodzeń do 30.12.2025 (FCEB). Rekomendacja CISA: identyczne podejście także w sektorze prywatnym.

Kontekst / historia / powiązania

Dodanie CVE-2025-62221 zbiegło się z grudniowym Patch Tuesday Microsoftu – to aktywnie wykorzystywany zero-day w komponencie Cloud Files Mini Filter. Niezależne przeglądy (Tenable, ZDI, media branżowe) wskazują na wysoki priorytet aktualizacji systemów Windows.

W przypadku WinRAR (CVE-2025-6218), podatność została opisana i skoordynowana przez Trend Micro ZDI już w czerwcu 2025 r., a producent wydał aktualizacje (WinRAR ≥ 7.12). Obecne dodanie do KEV oznacza potwierdzoną eksploatację „w dziczy”.

Analiza techniczna / szczegóły luki

CVE-2025-62221 – Windows Cloud Files Mini Filter (EoP)

Klasa błędu: Use-After-Free (CWE-416).
Wektor: lokalny; napastnik musi mieć niski poziom uprawnień (PR:L), brak interakcji użytkownika (UI:N).
Skutek: eskalacja uprawnień do SYSTEM.
Oceny/deskryptory: CVSS 3.1 (w publikacjach branżowych określana jako istotna EoP), 0-day.
Patch/porady: publikowane w ramach Patch Tuesday, wpis w MSRC.

CVE-2025-6218 – WinRAR Path Traversal (RCE)

Klasa błędu: CWE-22 (path traversal) w obsłudze ścieżek wewnątrz archiwów.
Wektor: zdalny, wymagana interakcja (otwarcie pliku/odwiedzenie strony).
Skutek: zdalne wykonanie kodu z uprawnieniami bieżącego użytkownika.
Łatki: WinRAR ≥ 7.12; dorobek analityczny i oś czasu ujawnienia w ZDI.

Praktyczne konsekwencje / ryzyko

Łańcuchy ataku:
- Windows EoP (CVE-2025-62221) – typowy drugi etap po początkowym naruszeniu (phishing, makro, przeglądarka, sterownik). Eskalacja do SYSTEM ułatwia trwałość, wyłączenie EDR, zrzuty LSASS i lateral movement.
- WinRAR (CVE-2025-6218) – realny wektor dostarczania przez e-mail/www (fałszywe archiwa .rar/.zip). „Klikalność” użytkowników i powszechność WinRAR czynią z tego vektora atrakcyjny nośnik malware.
Zasięg środowisk: Windows klient/serwer (EoP) oraz stacje użytkowników z WinRAR (RCE). Ryzyko rośnie w organizacjach z wysokim odsetkiem BYOD i brakiem centralnych aktualizacji aplikacji. (Wpisy KEV i przeglądy Patch Tuesday).

Rekomendacje operacyjne / co zrobić teraz

1) Łatanie i łagodzenia

Windows: niezwłocznie wdrożyć grudniowe poprawki – szczególnie dla komponentu Cloud Files Mini Filter (CVE-2025-62221). Priorytet: systemy z kontami uprzywilejowanymi i hosty brzegowe/jumphony.
WinRAR: wymusić wersję ≥ 7.12. Rozważyć odinstalowanie WinRAR tam, gdzie nie jest wymagany biznesowo. Blokada uruchamiania starszych binariów przez AppLocker/WDAC.

2) Kontrole detekcyjne i twardnienie

Monitorować nietypowe zdarzenia EoP i tworzenie usług/scheduler tasks po aktualnych exploitach (telemetria EDR/Sysmon). (Korelacja z datą 2025-12-09).
Dla WinRAR: filtrować załączniki .rar/.zip z podejrzanymi ścieżkami, sandboxing dynamiczny, reguły YARA dla znanych łańcuchów nadużyć ZDI.
Wymusić MOTW/SmartScreen/ASR dla pobranych archiwów; blokować makra i skrypty z katalogów tymczasowych.

3) GRC / zarządzanie podatnościami

Oznaczyć oba CVE jako „KEV – priorytet 1” i domknąć SLA ≤ 21 dni (zgodnie z BOD 22-01 – dla FCEB termin 30.12.2025). Dokumentować wyjątki i kompensacje.

Różnice / porównania z innymi przypadkami

EoP vs. RCE: Windows CVE-2025-62221 wymaga wstępnego dostępu, ale daje SYSTEM; CVE-2025-6218 może doprowadzić do RCE z uprawnieniami użytkownika – oba komponują się w kill chain (najpierw RCE na stacji, potem EoP).
Okno dowozu: Obie pozycje trafiły do KEV tego samego dnia, co usuwa dyskusję „co pierwsze” – łatamy oba przed końcem grudnia.

Podsumowanie / kluczowe wnioski

Dwie nowe pozycje KEV (9.12.2025): CVE-2025-62221 (Windows EoP) i CVE-2025-6218 (WinRAR RCE).
Termin CISA: 30.12.2025 – realny, krótki horyzont wdrożeniowy.
Plan minimum: natychmiastowy rollout poprawek Windows, aktualizacja/wycofanie WinRAR, wzmocnienie filtracji archiwów i telemetrii EDR.

Źródła / bibliografia

NVD (CVE-2025-62221) – wpis z adnotacją KEV, daty dodania i terminu. (NVD)
NVD (CVE-2025-6218) – wpis z adnotacją KEV, daty dodania i terminu; referencje ZDI i WinRAR. (NVD)
ZDI-25-409 – szczegóły techniczne WinRAR Path Traversal i oś czasu. (zerodayinitiative.com)
Tenable – Patch Tuesday (grudzień 2025) – podsumowanie i priorytetyzacja, wzmianka o CVE-2025-62221. (Tenable®)
Zero Day Initiative / ZDI Blog & ZDI listy oraz ZDI/Qualys/ZDI-partnerzy – przekrojowe omówienia grudniowych łatek (wspomagające priorytetyzację). (zerodayinitiative.com)