Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 413 z 487

Autor: Wojciech Ciemski

ConsentFix: nowa technika przejęcia kont Microsoft przez nadużycie OAuth w aplikacji Azure CLI

Wprowadzenie do problemu / definicja luki

Badacze z Push Security opisali nową technikę phishingu „ConsentFix”, która łączy wzorce ClickFix z nadużyciem OAuth consent i aplikacji Azure CLI. Atak pozwala przejąć dostęp do kont Microsoft (Entra/Microsoft 365) bez phishingu haseł i z ominięciem MFA, jeśli ofiara jest już zalogowana w przeglądarce. Kluczowy trik to wyłudzenie kodu autoryzacyjnego OAuth i skojarzenie konta ofiary z instancją Azure CLI napastnika.

W skrócie

  • Wektor: złośliwe/zhakowane strony z wysokim rankingiem w Google, fałszywy „Cloudflare Turnstile”, następnie instrukcje w stylu ClickFix.
  • Cel: uzyskać URL do localhost zawierający authorization code dla aplikacji Azure CLI i kazać ofierze wkleić go w stronę atakującego.
  • Efekt: napastnik wymienia kod na token(y) i zyskuje dostęp do danych/operacji w ramach uprawnień Azure CLI – bez hasła i bez dodatkowej weryfikacji MFA.
  • Dlaczego działa: Azure CLI jest aplikacją pierwszej strony Microsoft, zwykle domyślnie ufaną w Entra ID i niepodlegającą typowym ograniczeniom nakładanym na aplikacje zewnętrzne.
  • Mitigacje: zaostrzenie zasad User Consent, workflow Admin Consent, monitoring logowań Azure CLI i szybkie unieważnianie przyznań/zgód.

Kontekst / historia / powiązania

ConsentFix wpisuje się w ewolucję ataków na OAuth consent i ClickFix – zamiast kraść hasła, przestępcy polują na granty i tokeny. Wcześniej obserwowaliśmy m.in. AiTM i nowszy CoPhish, który nadużywał agentów Microsoft Copilot Studio do prezentowania legalnie wyglądających próśb o zgodę. Wspólny mianownik: legitymizacja przez domeny i aplikacje Microsoft oraz socjotechnika wokół przepływów OAuth.

Analiza techniczna / szczegóły luki

  1. Dostarczenie przynęty: ofiara trafia z wyszukiwarki na przejętą stronę; skrypt weryfikuje domenę e-mail (tylko „pożądane” organizacje idą dalej). Widać fałszywy widget Cloudflare Turnstile.
  2. Scena ClickFix: strona instruuje, aby kliknąć „Sign in”, co otwiera prawdziwy adres logowania Microsoft dla przepływu OAuth aplikacji Azure CLI.
  3. Authorization Code: po wybraniu konta (lub zalogowaniu) przeglądarka przekierowuje na http://localhost/... z parametrem code= (authorization code) – to standard w przepływach OAuth (authorization code / device flows).
  4. Exfiltracja: instrukcje nakazują skopiować cały URL i wkleić go w oknie na złośliwej stronie; skrypt po stronie atakującego wymienia code→token w kontekście aplikacji Azure CLI.
  5. Dlaczego bez sekretu? W tym scenariuszu kod wystarcza do pozyskania tokenu (aplikacje klienckie nie przechowują tajemnicy), więc mechanizm MFA/hasła nie chroni – sesja przeglądarki już uwierzytelnia użytkownika.
  6. Utrudnienia analizy: jednorazowość na IP, warunkowe ładowanie skryptów, selekcja celów, co znacznie utrudnia IOC-based detekcję.

Uwaga: Microsoftowa dokumentacja potwierdza, że device/authorization flows mogą kończyć się tokenem po poprawnym zalogowaniu i konsencie – to cecha protokołu, nie błąd implementacji. Problemem jest socjotechnika i nadużycie zaufanej aplikacji.

Praktyczne konsekwencje / ryzyko

  • ATO bez hasła i bez MFA: wystarczy aktywna sesja w przeglądarce i kilka kliknięć/kopiuj-wklej.
  • Zaufana aplikacja: Azure CLI jako first-party bywa wyłączony z restrykcji wobec app consent, co zwiększa powierzchnię nadużyć.
  • Dostęp szerokiego zakresu: w zależności od przyznanych/wykorzystanych uprawnień – potencjał na odczyt maili, plików, automatyzację operacji i pivot w M365/Azure. (Kierunek zgodny z wcześniejszymi kampaniami na tokeny OAuth).
  • Detekcja logowań wymaga patrzenia na zdarzenia sign-in specyficzne dla Azure CLI i nietypowe zakresy/stare Graph scopes.

Rekomendacje operacyjne / co zrobić teraz

1) Zaostrz politykę User Consent i włącz Admin Consent workflow

  • Ogranicz lub wyłącz zgody użytkowników; dopuszczaj wyłącznie zweryfikowanych wydawców i/lub niskiego ryzyka. Włącz Admin Consent workflow do obsługi próśb.

2) Monitoruj i reaguj

  • Ustal detektory na logowania Azure CLI z nowych lokalizacji/agentów oraz na przyznania zgody/zakresy nietypowe dla Twojej organizacji. Rekomendacje Push: poluj na sygnały związane z Azure CLI i „legacy Graph scopes”.
  • W razie incydentu: cofnij zgody/połączenia (Enterprise Apps), unieważnij refresh tokeny i wymuś ponowną autoryzację. (Patrz sekcja przeglądu i cofania zgód w Entra).

3) Twarde zasady wokół aplikacji i portali

  • Minimalizuj powierzchnię ataku: klastryzacja uprawnień, ograniczenia dostępu do portali, minimalizacja ról z prawem do przyznawania zgód. (Wytyczne dot. consent policies).

4) Edukacja użytkowników (anty-ClickFix)

  • Szkolenia ukierunkowane na „kopiuj-wklej z instrukcji wideo/strony” i fałszywe widgety weryfikacyjne. Podkreślaj: nigdy nie wklejać URL-i z kodami w obce formularze. (Wzorce opisane przez Push).

5) Testy kontroli i purple teaming

  • Przećwicz scenariusz: wyszukiwarka → „weryfikacja Cloudflare” → „Sign in” → localhost z code= → exfil. Sprawdź, które alerty zadziałały i gdzie brakuje telemetrii.

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

  • AiTM: kradnie sesje przez proxy logowania; ConsentFix poluje na granty OAuth i działa w kontekście przeglądarki bez pośredniczącej bramki.
  • CoPhish (Copilot Studio): także nadużywa zaufania do domen Microsoft i flow OAuth, ale przynętą są agenci Copilot z wbudowanymi przyciskami zgody. ConsentFix zamiast tego wyłudza kod z przepływu Azure CLI.

Podsumowanie / kluczowe wnioski

ConsentFix pokazuje, że obronność oparta wyłącznie na MFA i filtracji e-maili nie wystarczy wobec browser-native nadużyć OAuth i aplikacji pierwszej strony. Trzonem obrony musi być governance zgód, dojrzały threat hunting w logach Entra/Defender oraz ukierunkowana edukacja anty-ClickFix.

Źródła / bibliografia

  • Push Security: „ConsentFix – browser-native ClickFix hijacks OAuth grants” (11.12.2025). (Push Security)
  • BleepingComputer: „New ConsentFix attack hijacks Microsoft accounts via Azure CLI” (11.12.2025). (BleepingComputer)
  • Microsoft Learn: „Configure how users consent to applications” (aktualizacja 24.06.2025). (Microsoft Learn)
  • Microsoft Learn: „OAuth 2.0 device authorization grant flow” (aktualizacja 04.01.2025) – tło protokołu. (Microsoft Learn)
  • TechRadar: „CoPhish… steals OAuth tokens via Copilot Studio” (10.2025) – kontekst trendu. (TechRadar)

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)

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

  1. SecurityWeek – przegląd kampanii, typy malware, statystyki Shadowserver, KEV/terminy CISA: „Wide Range of Malware Delivered in React2Shell Attacks” (11 grudnia 2025). (SecurityWeek)
  2. 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)
  3. Huntress – szczegóły nowych rodzin (PeerBlight, CowTunnel, ZinFoq) i łańcuchów dystrybucji: „PeerBlight Linux Backdoor Exploits React2Shell”. (Huntress)
  4. Wiz – nacisk ataków na Next.js/Kubernetes, kradzież sekretów i Sliver: „React2Shell Deep Dive: CVE-2025-55182 Exploit Mechanics”. (wiz.io)
  5. 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 „Ekspert To Rola Nadawana Przez Innych – Nie Liczba Lat W CV”

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):

  1. Nie instaluj APK spoza Google Play; jeżeli musisz – tylko od sprawdzonych wydawców. Włącz i nie wyłączaj Google Play Protect.
  2. Zachowaj nieufność wobec żądań Accessibility/Device Admin – szczególnie gdy pojawiają się od razu po instalacji.
  3. 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).
  4. 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

  1. Zimperium (raport techniczny, 10 grudnia 2025): „Total Takeover: DroidLock Hijacks Your Device”. (zimperium.com)
  2. BleepingComputer (news, 10 grudnia 2025): „New DroidLock malware locks Android devices and demands a ransom”. (BleepingComputer)
  3. SiliconANGLE (news/omówienie, 10 grudnia 2025): „New DroidLock threat gives attackers near-total control of Android phones”. (SiliconANGLE)
  4. Trend Micro (poradnik, 27 października 2025): „Removing lock-screen type ransomware using Safe Mode on Android device”. (Trend Micro Success)
  5. 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)

  1. 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).
  2. 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.
  3. 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.)
  4. 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).
  5. 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

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