Archiwa: Malware - Security Bez Tabu

Tag: Malware

Microsoft unieważnia ponad 200 certyfikatów, by zablokować kampanię Rhysida — co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Microsoft poinformował, że w początku października 2025 r. zakłócił kampanię prowadzącą do wdrożeń ransomware Rhysida, unieważniając ponad 200 certyfikatów używanych do podpisywania złośliwych plików. Kampanię przypisano grupie Vanilla Tempest (znanej także jako Vice Spider / Vice Society). Złośliwe binaria podpisywano m.in. przy użyciu Trusted Signing oraz usług podpisywania kodu dostawców SSL.com, DigiCert i GlobalSign.

W skrócie

  • Vektor wejścia: fałszywe strony podszywające się pod witrynę pobierania Microsoft Teams (np. teams-download[.]buzz, teams-install[.]run, teams-install[.]top).
  • Payload: podpisany backdoor Oyster (znany też jako Broomstick/CleanUpLoader), wykorzystywany następnie do wdrożenia Rhysida.
  • Działanie obronne: Microsoft unieważnił >200 certyfikatów, aktualizując detekcje dla fałszywych podpisów oraz narzędzi kampanii.
  • Aktor: Vanilla Tempest — finansowo motywowany, znany z ataków na edukację i ochronę zdrowia, wcześniej wykorzystywał różne rodzinny ransomware (m.in. BlackCat, Quantum Locker, Zeppelin).

Kontekst / historia / powiązania

Vanilla Tempest to nowa nazwa taksonomiczna Microsoftu dla wcześniej trackowanego DEV-0832/Vice Society, znanego z ataków oportunistycznych i eklektycznego doboru ładunków szyfrujących.
Rhysida funkcjonuje w modelu RaaS i jest regularnym celem ostrzeżeń rządowych — najnowsza, zaktualizowana w 2025 r. notyfikacja CISA opisuje TTPs i IOC tej rodziny.
Backdoor Oyster był już wcześniej dystrybuowany przez malvertising/SEO-poisoning jako trojanizowane instalatory popularnych narzędzi (PuTTY, WinSCP, a ostatnio — Teams).

Analiza techniczna / szczegóły luki

Łańcuch ataku:

  1. Pozycjonowanie i reklamy kierowały ofiary na domeny łudząco podobne do legitymnych stron Teams.
  2. Pobierany plik MSTeamsSetup.exe był loaderem, który uruchamiał podpisaną wersję backdoora Oyster.
  3. Oyster zapewnia trwały, zdalny dostęp (kradzież plików, wykonywanie poleceń, dogrywanie ładunków), ułatwiając lateral movement i wdrożenie Rhysida.

Nadużycie zaufania:
Aktor wykorzystywał Trusted Signing (krótkoterminowe certyfikaty) oraz usługi podpisywania kodu SSL.com, DigiCert, GlobalSign, aby nadać artefaktom pozory wiarygodności (SmartScreen, AV/EDR trust). Microsoft przerwał kampanię przez hurtową revokację >200 certyfikatów powiązanych z fałszywymi instalatorami i narzędziami post-exploitation.

Praktyczne konsekwencje / ryzyko

  • Podpis ≠ bezpieczeństwo: Sam fakt podpisania binarium nie gwarantuje braku złośliwości. SOC-e powinny korelować podpisy z telemetrią uruchomień, siecią i zachowaniem.
  • Ryzyko supply-chain w userlandzie: Użytkownicy częściej „googlują” instalatory niż pobierają je z portali producenta — atak świetnie skaluje się na helpdeskach i w SMB.
  • Utrzymujące się TTPs: Nawet po revokacji certyfikatów aktor może się przegrupować z nowymi certyfikatami/infrastrukturą.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady domen/URL: natychmiast dodać do denylist znane domeny kampanii (teams-download[.]buzz, teams-install[.]run, teams-install[.]top, itp.) i monitorować pokrewne typosquaty.
  2. Źródła instalatorów: enforce’ować politykę pobierania oprogramowania wyłącznie z domen producenta; rozważyć blokadę pobrań EXE/MSI z wyszukiwarek.
  3. Kontrole podpisów: w EDR/SIEM budować reguły na anomalia podpisów (wydawca ≠ oczekiwany; chain do niedawno odwołanego certyfikatu; short-lived certs).
  4. Detekcje Oyster/Rhysida: wdrożyć najnowsze IOC/TTP z biuletynów branżowych i CISA; szukać nietypowych połączeń C2 oraz artefaktów loadera.
  5. Hardening przeglądarek/DNS: izolacja przeglądarek dla pobrań, DNS sinkhole dla domen malvertisingowych, blokada reklam na poziomie sieci.
  6. Edukacja użytkowników: krótkie runbooki „Jak bezpiecznie pobierać Teams” + banery w intranecie. (Źródła kampanii dowodzą skuteczności SEO-poisoningu).
  7. IR gotowość: playbook Ryusida/Oyster: containment hostów z podejrzanym MSTeamsSetup.exe, natychmiastowa rotacja poświadczeń, review logonów interaktywnych, hunting po sygnaturach podpisu.

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

W przeszłości widzieliśmy kradzione lub wyłudzone certyfikaty używane do podpisywania malware. Nowością jest systemowe nadużycie usług podpisywania (w tym Trusted Signing z krótką ważnością certyfikatów), co znacząco zwiększa tempo rotacji certyfikatów po stronie aktora i utrudnia proste bloki „na wydawcę”. Dzisiejsze zdarzenie pokazuje, że hurtowa revokacja i telemetria behawioralna są skuteczniejsze niż poleganie na samym zaufaniu do łańcucha certyfikacji.

Podsumowanie / kluczowe wnioski

  • >200 odwołanych certyfikatów to zdecydowany ruch, który obniża skuteczność kampanii, ale nie eliminuje ryzyka rearmowania się przeciwnika.
  • Fałszywe instalatory Teams + Oyster → Rhysida: łańcuch ataku był wiarygodny dzięki podpisom i SEO-poisoning.
  • Organizacje powinny wzmocnić kontrolę źródeł oprogramowania, reguły detekcji podpisów i higienę przeglądarkową.

Źródła / bibliografia

  1. SecurityWeek — „Microsoft Revokes Over 200 Certificates to Disrupt Ransomware Campaign”, 16 października 2025 r. (SecurityWeek)
  2. BleepingComputer — „Microsoft disrupts ransomware attacks targeting Teams users”, 16 października 2025 r. (BleepingComputer)
  3. CISA — „#StopRansomware: Rhysida Ransomware” (zaktualizowane 30 kwietnia 2025 r.). (CISA)
  4. Microsoft Security Blog — „DEV-0832 (Vice Society)…” (mapowanie do Vanilla Tempest), 25 października 2022 r. (Microsoft)
  5. Broadcom / Symantec — „Oyster backdoor spread via malicious Teams setup”, 29 września 2025 r. (Broadcom)

Korea Płn. ukrywa malware w blockchainie: jak działa EtherHiding i co to oznacza dla obrony?

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence (Mandiant) potwierdziło, że aktor państwowy z Korei Północnej (UNC5342) zaczął wykorzystywać publiczne blockchainy (Ethereum, BNB Smart Chain) do ukrywania i dostarczania złośliwego kodu. Technika znana jako EtherHiding osadza ładunki w smart kontraktach, co utrudnia blokowanie i „takedown” — kod pozostaje dostępny tak długo, jak działa sam blockchain. To pierwszy znany przypadek adopcji tej metody przez aktora państwowego.

O odkryciu poinformował również serwis The Record (Recorded Future News), który podkreśla, że kampania łączy socjotechnikę na deweloperach z loaderem JADESNOW i backdoorem INVISIBLEFERRET używanym w kradzieżach krypto.

W skrócie

  • Co nowego? Korea Płn. przenosi delivery/C2 do smart kontraktów (Ethereum/BSC), korzystając z bezpłatnych zapytań eth_call do pobierania ładunków bez śladów on-chain (brak opłat/gazu).
  • Po co? Decentralizacja = odporność na zdejmowanie infrastruktury i listy blokujące; możliwość zdalnych, cichych aktualizacji łańcucha infekcji.
  • Jakie malware? Loader JADESNOW → wariant JS INVISIBLEFERRET (oraz inne moduły), wcześniej obserwowane w kradzieżach kryptowalut.
  • Kogo celują? Deweloperzy (krypto/tech), rekrutacje „Contagious Interview” i zadania techniczne z trojanizowanymi paczkami npm/VSC.

Kontekst / historia / powiązania

EtherHiding nie jest całkiem nowe: po raz pierwszy opisano je w 2023 r. jako element kampanii CLEARFAKE, która podszywała się pod aktualizacje przeglądarki i osadzała JS w kontraktach BSC. Wówczas była to taktyka finansowo motywowanego UNC5142; dziś po raz pierwszy adoptuje ją aktor państwowy (UNC5342).

Dopełnieniem tła są długotrwałe kampanie DPRK na rynku krypto (fałszywi rekruterzy, pakiety npm, drenaż portfeli). Unit 42 opisało je jako Contagious Interview – podszywanie pod headhunterów, zadania techniczne, łańcuchy z loaderami i backdoorami.

Równolegle Cisco Talos dokumentuje ewolucję narzędzi powiązanych z DPRK (np. BeaverTail, OtterCookie) oraz częste instalowanie INVISIBLEFERRET w podobnych klastrach aktywności. To spójne z obserwacjami Google dot. kampanii na deweloperów.

Analiza techniczna / szczegóły luki

Łańcuch ataku (wysoki poziom):

  1. Initial access: socjotechnika (LinkedIn/komunikatory), fikcyjne firmy, „zadanie rekrutacyjne” → pobranie paczki z npm/GitHub.
  2. Loader: niewielki skrypt JS (JADESNOW) wstrzykiwany do projektu/środowiska.
  3. On-chain fetch: skrypt wykonuje zapytania read-only (np. eth_call) do smart kontraktu w Ethereum/BSC, odczytując zaszyfrowane (Base64 + XOR) dane wejściowe z przechowywanych zmiennych/zdarzeń. Brak transakcji = brak śladu on-chain + brak opłat.
  4. Dekodowanie/egzekucja: odszyfrowany JS uruchamia JADESNOW → dostarcza INVISIBLEFERRET (JS/Python), opcjonalnie doładowuje infostealery; payload bywa przełączany między łańcuchami (Ethereum ↔ BSC) dla utrudnienia analizy i optymalizacji kosztów gazu.

Dlaczego to działa?

  • Decentralizacja i niezmienność utrudniają zrywanie łańcucha C2/delivery (brak „serwera” do przejęcia), a autor kontraktu może aktualizować dane/pola zgodnie z ABI i w okamgnieniu zmieniać konfigurację kampanii.
  • Warstwa dostępu: mimo że kontrakt jest permissionless, operatorzy często korzystają z centralizowanych usług API (np. dostawcy endpointów), które stanowią jedyny punkt obserwacji/zakłócenia dla obrońców.

Pochodzenie techniki: Guardio Labs opisało EtherHiding w 2023 r. w kontekście CLEARFAKE (kompromitowane strony WordPress, fałszywe aktualizacje, ładunki JS w BSC), co stanowiło „bulletproof hosting 2.0”.

Praktyczne konsekwencje / ryzyko

  • Takedown-resistance: klasyczne playbooki (sinkhole, hosting takedown, blokada domen) są mało skuteczne – kod żyje w łańcuchu. Blue team musi celować w punkty pośrednie: dostawców RPC/API, reguły sieciowe, łańcuchy deszyfracji.
  • Low-noise delivery: eth_call nie tworzy transakcji, więc logika ładowania jest „cicha” – brak detekcji opartej na anomaliach transakcyjnych.
  • Supply-chain & dev tooling: wektor przez npm/VS Code/IDE zwiększa ryzyko dla zespołów R&D i CI/CD; paralela do kampanii opisywanych przez Unit 42 i Talos.

Rekomendacje operacyjne / co zrobić teraz

Detection & telemetry

  • Egress/DNS/HTTP(S): profiluj i blokuj nietypowe połączenia do publicznych API blockchain (np. etherscan.io, bscscan.com, komercyjni providerzy RPC), jeśli hosty nie są potrzebne biznesowo. Twórz wyjątki per zespół krypto.
  • Content inspection: YARA/Detections na artefakty JADESNOW/INVISIBLEFERRET oraz sekwencje Base64+XOR w JS; hunting na wywołania Web3 (eth_call, eth_getLogs) z kontekstu przeglądarki/Node.
  • IDE & package security: enforce’uj blokady pobierania paczek npm z niezatwierdzonych źródeł; skanery SCA/typosquatting; monitoruj podejrzane rozszerzenia VS Code. (Zbieżne z obserwacjami Talos i Unit 42).

Hardening & procesy

  • Separacja środowisk dev: kontenery/VM z ograniczeniami sieciowymi; brak dostępu do kluczy produkcyjnych i walletów z maszyn deweloperskich.
  • Polityka RPC: jeżeli Web3 jest wymagane, kieruj ruch przez własne bramki/proxy z inspekcją i listą dozwolonych adresów kontraktów.
  • AppSec: CSP/Trusted Types, blokowanie wstrzyknięć JS na stronach WWW, ochrona WordPress (CLEARFAKE wciąż infekuje serwisy).
  • Szkolenia & Playbooks: tabletop wokół „fałszywej rekrutacji”, weryfikacja zadań technicznych, zasada „no binary from chat/IM”, procedury IR dla łańcuchów Web3.

IOC/Threat intel

  • Wykorzystaj wskazane przez Google adresy kontraktów/artefakty (np. przykładowy adres BSC z analizy) do budowy reguł blocklist i TI – pamiętając, że atakujący mogą szybko zmieniać wartości on-chain.

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

  • CLEARFAKE (UNC5142, 2023–): motywacja finansowa, infekcje WordPress i fałszywe aktualizacje przeglądarki; EtherHiding było tam nośnikiem infostealerów. UNC5342 (2025): adopcja przez aktora państwowego, wektor rekrutacyjny na devów, łańcuch z JADESNOW → INVISIBLEFERRET i kradzieże krypto.
  • BeaverTail/OtterCookie (Talos): inny klaster DPRK ukierunkowany na deweloperów; wspólne TTP (fałszywe oferty pracy, npm), ale niekoniecznie używa EtherHiding. Pokazuje jednak szeroką dywersyfikację narzędzi DPRK.

Podsumowanie / kluczowe wnioski

EtherHiding przenosi delivery/C2 do warstwy, której nie można „wyłączyć”. Wejście aktora państwowego do gry (UNC5342) przyspieszy adopcję tej techniki w APT i cyberprzestępczości. Obrona musi przestawić się na kontrolę dostępu do providerów RPC/API, hunting artefaktów Web3 w JS i twarde procesy bezpieczeństwa w zespołach deweloperskich.

Źródła / bibliografia

  1. Google Cloud Blog (GTIG/Mandiant): DPRK Adopts EtherHiding: Nation-State Malware Hiding on Blockchains, 16.10.2025. (Google Cloud)
  2. The Record (Recorded Future News): North Korean hackers seen using blockchain to hide crypto-stealing malware, 16.10.2025. (The Record from Recorded Future)
  3. Guardio Labs: Hiding Web2 Malicious Code in Web3 Smart Contracts (EtherHiding), 13.10.2023. (Guardio)
  4. Palo Alto Networks Unit 42: Contagious Interview – DPRK Threat Actors Lure Tech Job Seekers as Fake Recruiters, 09.10.2024. (Unit 42)
  5. Cisco Talos: BeaverTail and OtterCookie evolve with a new JavaScript module, 16.10.2025. (Cisco Talos Blog)

Fałszywe alerty „wycieku” LastPass i Bitwarden kończą się przejęciem komputera. Jak działa kampania i jak się bronić

Wprowadzenie do problemu / definicja luki

Trwa kampania phishingowa podszywająca się pod LastPass i Bitwarden. Ofiary otrzymują e-maile informujące o rzekomym włamaniu i pilnej konieczności zainstalowania „bezpieczniejszej” wersji aplikacji desktopowej. Po kliknięciu linku i uruchomieniu pliku instalowany jest agent narzędzia RMM, a następnie ScreenConnect (zdalny pulpit), co umożliwia atakującemu pełne przejęcie stacji roboczej. To nie jest prawdziwy incydent po stronie LastPass/Bitwarden — to socjotechnika.

W skrócie

  • Temat: podszywanie się pod LastPass/Bitwarden z fałszywymi „alertami o włamaniu”.
  • Wejście: e-mail z domen typu lastpasspulse.blog, lastpasjournal.blog, bitwardenbroadcast.blog z linkiem do „nowej aplikacji desktopowej”.
  • Łańcuch infekcji: instalacja Syncro (RMM) → doinstalowanie ScreenConnect → zdalne przejęcie hosta, możliwość dołożenia malware i kradzieży danych.
  • Stan faktyczny: LastPass potwierdza, że nie doszło do włamania; wskazuje IoC (domeny, IP) i że strony są blokowane jako phishing.
  • Powiązane: tydzień wcześniej podobny schemat uderzał w użytkowników 1Password (phishing na „Watchtower”).

Kontekst / historia / powiązania

Napastnicy coraz częściej celują w menedżery haseł — zaufane marki zwiększają skuteczność socjotechniki, a przejęcie takiego konta daje dostęp do wielu usług. Oprócz obecnej fali na LastPass/Bitwarden, w październiku 2025 opisana została kampania podszywająca się pod 1Password (fałszywe alerty Watchtower, domena phishingowa i przekierowania przez Mandrill). Widzimy więc trend ataków „brand-impersonation” w obrębie tej kategorii narzędzi.

Analiza techniczna / szczegóły kampanii

Wejście (Initial Access):

  • E-maile o temacie w stylu „We Have Been Hacked – Update Your … Desktop App…”, nadawcy m.in. hello@lastpasspulse[.]blog, hello@lastpassgazette[.]blog, hello@lastpasjournal[.]blog oraz wariant dla Bitwarden (hello@bitwardenbroadcast[.]blog). Linki prowadzą do stron typu lastpassdesktop[.]com / lastpassgazette[.]blog.

Środowisko hostingu i blokady:

  • Domeny były osłaniane przez Cloudflare i oznaczane jako phishing; odnotowano wykorzystanie hostingu kojarzonego z „bulletproof” dostawcami.

Wykonanie (Execution) i triks techniczne:

  • Pobierany binarny „installer” nie jest aplikacją menedżera haseł. To agent Syncro (RMM) uruchamiany z parametrami ukrywającymi ikonę w trayu. Po zestawieniu łączności agent dociąga ScreenConnect (BYO installer), który daje atakującemu interaktywny zdalny dostęp. Konfiguracja ograniczona do minimum (check-in co 90 s), bez włączonego natywnego zdalnego dostępu w Syncro i bez dodatkowych integracji typu Splashtop/TeamViewer; skrypty wyłączają lub blokują agentów Emsisoft/Webroot/Bitdefender.

Cel (Impact):

  • Po ustanowieniu sesji RDP-like atakujący może: doinstalować infostealery/ransomware, eksfiltrację danych, przejąć przeglądarki/menedżery haseł (po odblokowaniu sesji użytkownika), pivotować w sieci.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy indywidualni: ryzyko kradzieży całej „skrzynki z kluczami” (vault), danych finansowych i tożsamości; potencjalne szyfrowanie danych.
  • Firmy/MSP: RMM jako „żywe z ziemi” (LOTL) utrudnia detekcję; możliwe obejście części EPP/AV; ekspozycja poświadczeń korporacyjnych i danych klientów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesków:

  1. Ignoruj i raportuj: nie instaluj „nowej aplikacji desktopowej” z linków e-mail; zgłaszaj do dostawcy (np. abuse@lastpass.com).
  2. Weryfikuj komunikaty wyłącznie w panelu/kanałach oficjalnych (blog, status, help). Firmy nie proszą o podanie master password w e-mailu.
  3. Sprawdź legalność wiadomości Bitwarden – oficjalne maile nie mają załączników i nie proszą o pobranie pliku.
  4. EDR/AV skan pełny i audyt uruchomionych usług: poszukaj Syncro/ScreenConnect; w razie znajdowania – izoluj host, resetuj hasła (zwłaszcza do menedżera haseł) i weryfikuj MFA.
  5. Ustaw reguły blokujące instalację i komunikację popularnych RMM (allow-list w firmach), segmentacja i zasada najmniejszych uprawnień na stacjach helpdesk.

Dla zespołów bezpieczeństwa/SOC:

  • Blokuj IoC z poniższej listy na bramkach i EDR; huntuj po DNS/HTTP/S, procesach i usługach (np. SyncroMSP, artefakty ScreenConnect).
  • User awareness: krótkie szkolenie o „fałszywych wyciekach” i wzorcach stylu (nagłówki, słownictwo, presja czasu, weekendowe wysyłki).

Wybrane IoC (na podstawie bieżących publikacji):

  • Nadawcy: hello@lastpasspulse[.]blog, hello@lastpassgazette[.]blog, hello@lastpasjournal[.]blog, hello@bitwardenbroadcast[.]blog.
  • Domeny/URL: lastpassdesktop[.]com, lastpassgazette[.]blog, potencjalnie lastpassdesktop[.]app.
  • Infrastruktura (wg LastPass w chwili publikacji): IP 172.67.147[.]36, 172.67.219[.]2, 84.32.84[.]32; nagłówkowe IP 148.222.54[.]15, 23.83.222[.]47. Uwaga: adresy mogą się zmieniać – utrzymuj bloki jako time-boxed.
  • Narzędzia po stronie ofiary: Syncro (RMM) → ScreenConnect (zdalny dostęp).

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

  • Obecna kampania (LastPass/Bitwarden): główny cel to przejęcie endpointu poprzez RMM i zdalny dostęp (ScreenConnect). Nie chodzi tylko o kradzież danych logowania z fałszywej strony, ale o pełną kontrolę nad hostem.
  • Kampania na 1Password (tydzień wcześniej): klasyczny credential phishing (np. link do fałszywej strony po przekierowaniu), bez instalacji RMM; wektor oparty o „Watchtower breach alert”.

Podsumowanie / kluczowe wnioski

  • Nie doszło do nowego włamania do LastPass ani Bitwarden — to fałszywe alerty.
  • Kliknięcie w link i instalacja „nowej aplikacji” kończy się instalacją RMM i zdalnym przejęciem komputera.
  • Trend: rośnie liczba kampanii podszywających się pod marki menedżerów haseł (LastPass, Bitwarden, 1Password). Weryfikuj komunikaty tylko w oficjalnych kanałach i egzekwuj polityki blokowania RMM.

Źródła / bibliografia

  • BleepingComputer: Fake LastPass, Bitwarden breach alerts lead to PC hijacks (analiza kampanii, łańcuch RMM → ScreenConnect). (BleepingComputer)
  • LastPass (oficjalny blog): October 13 Phishing Campaign Leveraging LastPass Branding — dementi, IoC (domeny, IP), wskazówki. (The LastPass Blog)
  • Malwarebytes: Phishers target 1Password users with convincing fake breach alert — kontekst i podobna kampania tydzień wcześniej. (Malwarebytes)
  • Bitwarden Help Center: Identify Legitimate Emails from Bitwarden — jak rozpoznać prawdziwe maile (brak załączników/plików). (Bitwarden)

Krytyczne ryzyko łańcucha dostaw w marketplace’ach rozszerzeń VS Code: co odkrył Wiz i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Zespół Wiz Research ujawnił 15 października 2025 r. systemowy problem bezpieczeństwa w ekosystemie rozszerzeń VS Code: setki kluczy i tokenów dostępowych zostały nieumyślnie spakowane w paczki rozszerzeń i opublikowane w Visual Studio Code Marketplace oraz Open VSX. W ponad stu przypadkach były to tokeny umożliwiające… aktualizację samego rozszerzenia — a ponieważ VS Code domyślnie autoaktualizuje rozszerzenia, przejęcie takiego tokenu pozwalałoby rozesłać złośliwą aktualizację do całej bazy instalacji danego rozszerzenia.

W skrócie

  • Wiz znalazł 550+ ważnych sekretów w 500+ rozszerzeniach od setek wydawców; w tym tokeny Azure DevOps (VS Marketplace) i Access Tokens Open VSX. Łącznie dotknięta baza instalacji to ponad 85 tys. (VS Marketplace) i 100 tys. (Open VSX).
  • Po zgłoszeniu przez Wiz, Microsoft włączył skanowanie sekretów i blokowanie publikacji rozszerzeń zawierających wykryte klucze; skanowanie objęło też istniejące rozszerzenia.
  • Open VSX wprowadził prefiks tokenu („ovsxp_”) ułatwiający wykrywanie wycieków przez narzędzia skanujące.

Kontekst / historia / powiązania

Ryzyko łańcucha dostaw w IDE narasta od lat: rozszerzenia mają dostęp do środowiska dewelopera i mogą wykonywać kod. Microsoft dokumentował mechanizmy kontroli i „trust” w runtime rozszerzeń, ale tajne klucze w paczkach to inny wektor — działa poza samym silnikiem uprawnień: atak następuje na etapie publikacji/aktualizacji. Dlatego Microsoft zapowiedział i wdrożył „Secret Detection for Extensions” w Marketplace, a dodatkowo opisał szerszy plan podniesienia zaufania do ekosystemu.

Analiza techniczna / szczegóły luki

Wiz rozpakowywał paczki .vsix (to zwykłe archiwa ZIP) i znajdował w nich m.in.:

  • Dotfiles i pliki konfiguracyjne (np. .env, config.json, mcp.json, .cursorrules) zawierające klucze;
  • Twardo zakodowane sekrety w kodzie/package.json/README;
  • Tokeny wydawców:
    • Azure DevOps PAT (dla publikacji do VS Marketplace),
    • Open VSX Access Tokens (dla Open VSX).

Najgroźniejsze były tokeny publikacyjne — przejęcie ich pozwalałoby wypchnąć złośliwą wersję do całej bazy odbiorców danego rozszerzenia (przy włączonym auto-update). Wiz potwierdził 100+ ważnych PAT-ów VS Marketplace (ok. 85 tys. instalacji) oraz 30+ tokenów Open VSX (ok. 100 tys. instalacji).

Praktyczne konsekwencje / ryzyko

  • Masowa dystrybucja malware przez zaufany kanał aktualizacji rozszerzeń.
  • Ukierunkowane ataki na firmy korzystające z wewnętrznych/„vendor-specific” rozszerzeń opublikowanych publicznie „dla wygody”.
  • „Fałszywe poczucie bezpieczeństwa” przy motywie/tematach (themes) — choć zwykle nie zawierają kodu, nic nie blokuje dołączenia złośliwych payloadów do takiej paczki.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów developerskich

  1. Minimalizacja rozszerzeń – instaluj tylko niezbędne; oceń reputację wydawcy, historię wersji i liczbę instalacji.
  2. Zarządzanie autoaktualizacją – rozważ kontrolowane okna aktualizacji i obserwację zmian uprawnień/rozmiaru paczki; w środowiskach korporacyjnych wdrażaj aktualizacje etapowo.
  3. Inwentaryzacja i „allowlista” rozszerzeń (VS Code wspiera centralne polityki).

Dla wydawców rozszerzeń

  1. CI gate na sekrety: uruchamiaj skanery sekretów (np. GitHub Advanced Secret Scanning/partner program) i blokuj build/publikację przy wykryciu.
  2. Higiena repo/paczki: usuń .env i inne dotfiles z artefaktów (.vscodeignore / konfiguracja vsce), rotuj i skracaj TTL dla tokenów.
  3. Migracja tokenów: używaj tokenów z identyfikowalną strukturą/prefiksem (np. ovsxp_ w Open VSX) – to zwiększa skuteczność ochrony.

Dla operatorów platform

  1. Blokowanie publikacji z sekretami (pre-publish scanning) i skan „retro” istniejących rozszerzeń. Microsoft ogłosił i włączył tryb blocking w VS Marketplace.
  2. Standardyzacja sekretów (prefiksy, checksumy, CASK) oraz krótkie TTL.
  3. Transparentność i roadmapa bezpieczeństwa — publikowanie postępów i zasad (jak w aktualizacji Microsoft z czerwca 2025).

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

Ta kampania nie polegała głównie na publikacji ewidentnie złośliwych rozszerzeń, ale na wyciekach sekretów wydawców, co czyni wektor wyjątkowo niebezpiecznym: atakujący może podszyć się pod legalnego wydawcę i wykorzystać auto-update. To odróżnia sprawę od „klasycznych” kampanii złośliwych pluginów, a reakcje platform (blokowanie publikacji, skan istniejących paczek, prefiksy tokenów) są tu kluczowe.

Podsumowanie / kluczowe wnioski

  • Łańcuch dostaw IDE to realny wektor ataku: sekret w paczce rozszerzenia = potencjał RCE przez zaufaną aktualizację.
  • Reakcja platform (blokowanie publikacji, retro-skan, prefiksy tokenów) znacząco zmniejsza ryzyko, ale higiena po stronie wydawców i zespołów pozostaje niezbędna.
  • Organizacje powinny wdrożyć allowlistę, inwentaryzację, kontrolowane aktualizacje oraz policyjne skanowanie sekretów w CI/CD.

Źródła / bibliografia

  1. Wiz Research: “Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (15 października 2025). (wiz.io)
  2. GitHub (Microsoft VS Marketplace): „Upcoming Security Enhancement: Secret Detection for Extensions” + ogłoszenie trybu blocking. (GitHub)
  3. Microsoft DevBlogs: „Security and Trust in Visual Studio Marketplace” (11 czerwca 2025). (Microsoft for Developers)
  4. Open VSX (Eclipse): dokumentacja prefiksu tokenów ovsx.token-prefix. (GitHub)
  5. VS Code Docs: „Extension runtime security” (sekcja o skanowaniu sekretów i blokowaniu publikacji). (Visual Studio Code)

Windows 10: koniec wsparcia od 14 października 2025 r. — co to oznacza dla bezpieczeństwa i zgodności?

Wprowadzenie do problemu / definicja luki

Microsoft zakończył dziś, 14 października 2025 r., standardowe wsparcie dla Windows 10 (wszystkich edycji 22H2). Od teraz system nie otrzymuje już bezpłatnych aktualizacji zabezpieczeń ani poprawek. Urządzenia będą działać, ale z miesiąca na miesiąc będą coraz bardziej narażone na ataki wykorzystujące nowe luki.

W skrócie

  • Data EoS: 14.10.2025 (koniec aktualizacji i pomocy technicznej).
  • Ostatnia wersja: 22H2 — ostatni release Windows 10.
  • Wyjątki: linie LTSC mają osobne cykle wsparcia.
  • ESU (konsumenci): 1 rok rozszerzonych łat bezpieczeństwa do 13.10.2026 r.; rejestracja: 0 zł (gdy synchronizujesz ustawienia z kontem Microsoft), 1000 punktów Rewards albo 30 USD jednorazowo. Limit do 10 urządzeń na licencję.
  • Microsoft 365 Apps: oficjalne wsparcie na Windows 10 wygasa dziś, ale aktualizacje zabezpieczeń dla M365 będą dostarczane jeszcze do 10.10.2028 r., by ułatwić migrację.

Kontekst / historia / powiązania

Windows 10 zadebiutował w 2015 r. i przez lata był „systemem jako usługą” z półrocznymi aktualizacjami. Microsoft ogłosił, że 22H2 to finalna wersja, a „dni łatkowania” kończą się w październiku 2025 r. Media branżowe od wielu miesięcy ostrzegały użytkowników i firmy przed pozostawaniem na niewspieranej platformie.

Analiza techniczna / szczegóły

Cykl życia i edycje

  • Home/Pro/Enterprise/Education (22H2): koniec wsparcia 14.10.2025.
  • LTSC (np. Enterprise LTSC): nadal wspierane wg własnych harmonogramów.
  • Brak nowych funkcji/driverów/poprawek po tej dacie.

ESU dla użytkowników domowych i SOHO (Consumer ESU)

Microsoft po raz pierwszy udostępnia program ESU dla konsumentów. Kluczowe parametry:

  • Zakres: tylko aktualizacje bezpieczeństwa „Critical/Important” (MSRC). Brak wsparcia technicznego, brak poprawek funkcjonalnych.
  • Dostępność: rejestracja przez Ustawienia → Aktualizacja i zabezpieczenia → Windows Update → Enroll now.
  • Warunki: Windows 10 22H2, konto Microsoft z uprawnieniami administratora.
  • Wyłączenia: urządzenia domenowe/Entra-joined, kiosk, MDM — to już scenariusze komercyjne (dla nich osobny, płatny ESU).
  • Cena/ opcje rejestracji: 0 zł (gdy włączona synchronizacja ustawień), 1000 Rewards, lub 30 USD (równowartość w lokalnej walucie); ważne do 13.10.2026 r.; licencję można użyć na maks. 10 urządzeń.

Microsoft 365 na Windows 10

Aplikacje Microsoft 365 formalnie kończą wsparcie na Windows 10 wraz z EoS, ale — w celu utrzymania bezpieczeństwa — Microsoft będzie dostarczał ich aktualizacje zabezpieczeń do 10.10.2028 r. To nie przywraca wsparcia systemu operacyjnego.

Praktyczne konsekwencje / ryzyko

  • Rosnąca powierzchnia ataku: nowe exploity nie będą łatane w OS bez ESU; z czasem wzrośnie liczba day-0/day-n wymierzonych w Windows 10.
  • Ryzyko zgodności/compliance: w sektorach regulowanych (np. RODO, ISO 27001) używanie niewspieranego OS może naruszać polityki bezpieczeństwa.
  • Łańcuch dostaw i urządzenia brzegowe: endpointy z Win10 bez ESU staną się najsłabszym ogniwem w sieci.
  • Użytkownicy indywidualni: wzrost prawdopodobieństwa infekcji malware/ransomware poprzez przeglądarkę, klienckie aplikacje i sterowniki. Media i Microsoft ostrzegają, że system pozostawiony bez łatek będzie z czasem coraz łatwiejszym celem.

Rekomendacje operacyjne / co zrobić teraz

  1. Sprawdź możliwość aktualizacji do Windows 11 (TPM 2.0, Secure Boot, nowsze CPU). Jeśli sprzęt spełnia wymagania — migruj niezwłocznie.
  2. Jeśli musisz zostać na Windows 10:
    • Zapisz urządzenie do ESU (konsumenckiego) od razu, aby nie pozostawiać luki w oknie bezłatkowym. Włącz synchronizację ustawień z kontem Microsoft, aby skorzystać z opcji bez opłaty, lub użyj 1000 punktów Rewards / 30 USD.
    • Wymuś twardą politykę zabezpieczeń: EDR/antywirus klasy enterprise, kontrola aplikacji, ograniczenie makr, segmentacja sieci, pełne szyfrowanie dysków.
    • Ogranicz ekspozycję: pracuj na koncie standardowym, aktualizuj przeglądarkę i aplikacje firm trzecich, wyłącz zbędne usługi/porty.
  3. Dla organizacji: rozważ komercyjny ESU (płatny, do 3 lat) i plan migracji do Windows 11/Windows 365. Zgodność i audyty powinny wymagać dat wyłączeń dla hostów Win10.
  4. Alternatywy dla sprzętu niespełniającego wymagań: Linux desktop lub modernizacja sprzętu; traktuj to jako most, nie docelowy stan bezpieczeństwa. (Rekomendacja ogólna; wybór zależny od profilu ryzyka i aplikacji.)

Różnice / porównania z innymi przypadkami

  • LTSC vs. standardowe edycje: LTSC zachowuje wsparcie według własnych terminów (dłuższe okna serwisowe), ale dotyczy specyficznych środowisk (urządzenia specjalistyczne).
  • ESU konsumenckie vs. komercyjne: Consumer ESU — 1 rok, prosty onboarding przez Windows Update; Commercial ESU — do 3 lat, zarządzanie kluczami/MDM, dla urządzeń domenowych/zarządzanych.
  • Windows 11: ciągłe łaty, funkcje zabezpieczeń (TPM 2.0, HVCI, Smart App Control, ulepszenia kernel/driver), aktywnie rozwijany ekosystem. (Kontekst migracyjny.)

Podsumowanie / kluczowe wnioski

  • Windows 10 bez ESU = niewspierany i podatny od 14.10.2025 r.
  • Masz trzy ścieżki: (1) migracja do Windows 11, (2) ESU na 1 rok (konsumenci) / do 3 lat (firmy), (3) wymiana/modernizacja sprzętu lub zmiana OS.
  • Jeśli pozostajesz na Win10 choćby tymczasowo — zapisz się do ESU natychmiast i podnieś poziom zabezpieczeń endpointów.

Źródła / bibliografia

  • Microsoft Support — „Windows 10 support ends on October 14, 2025” (daty EoS, M365 Apps). (Microsoft Support)
  • Microsoft Learn — cykl życia Windows 10 (22H2 ostatnią wersją; wyjątki LTSC). (Microsoft Learn)
  • Microsoft — „Windows 10 Consumer Extended Security Updates (ESU)” (warunki, cena, rejestracja, zakres). (Microsoft)
  • BleepingComputer — przypomnienie o EoS i zagrożeniach pozostania na Win10. (BleepingComputer)
  • The Verge — tło migracyjne i bariery sprzętowe Windows 11. (The Verge)

Android „Pixnapping”: nowy atak na piksele wykrada kody 2FA i dane z aplikacji

Wprowadzenie do problemu / definicja luki

Pixnapping to nowa klasa ataków na Androida pozwalająca złośliwej aplikacji „podejrzeć” zawartość ekranu innej aplikacji lub witryny – jakby robiła jej zdalny zrzut, ale bez uprawnień i bez interakcji użytkownika. Badacze pokazali, że możliwe jest m.in. odczytanie kodów 2FA z Google Authenticator, fragmentów Gmaila czy treści z aplikacji Signal i Venmo. Google przypisało podatności identyfikator CVE-2025-48561. Częściowa łatka znalazła się w biuletynie zabezpieczeń z września 2025, a pełniejsze poprawki Google zapowiada na grudzień 2025. Nie ma śladów wykorzystania „in the wild”.

W skrócie

  • Co to jest: Ramy ataku, które umożliwiają wyciek pikseli z ekranu innej aplikacji/strony poprzez zestaw legalnych API Androida i kanał boczny w GPU.
  • Na co działa: Zademonstrowano na Pixel 6–9 i Samsung Galaxy S25 (Android 13–16, do buildu BP3A.250905.014). Inne urządzenia najpewniej też są podatne.
  • Uprawnienia: Brak – złośliwa aplikacja nie potrzebuje żadnych zezwoleń w manifeście.
  • Szybkość wycieku: ~0,6–2,1 piksela/s – wystarczająco do odzyskania 6-cyfrowych kodów TOTP.
  • Status łatek: Wrzesień 2025 – częściowa, obejście istnieje; zapowiedziano kolejną w grudniu 2025.

Kontekst / historia / powiązania

Pixnapping łączy dwie linie badań:

  1. GPU.zip – kanał boczny wynikający z zależnej od danych, transparentnej dla oprogramowania kompresji graficznej w nowoczesnych GPU. Pozwala wnioskować o kolorze pikseli na podstawie czasu renderowania/pasmo pamięci.
  2. Android Custom Tabs / „Tabbed Out” – analiza modelu bezpieczeństwa komponentu Custom Tabs (IEEE S&P 2024), która zainspirowała część wektora inicjowania renderowania zawartości ofiary.

Artykuł The Register z 13 października 2025 opisuje Pixnapping i przytacza stanowisko Google o częściowej łatce (wrzesień) oraz planach na grudzień.

Analiza techniczna / szczegóły luki

Model zagrożenia. Zainstalowana aplikacja (bez specjalnych uprawnień) inicjuje sekwencję, w której:

  1. Wypycha piksele ofiary do potoku renderowania – np. uruchamia Google Authenticator/Gmail poprzez Android Intents, aby ich UI został narysowany.
  2. Nakłada półprzezroczyste „Activities” nad wybranym obszarem ekranu i indukuje operacje graficzne (użyto window blur API). Czas renderowania zależy od danych (koloru piksela).
  3. Mierzy czas (VSync callbacks) i przez kanał boczny GPU.zip odtwarza wartości pikseli – następnie OCR składa znaki (np. cyfry TOTP).

Dlaczego to działa? W GPU (np. Mali w Pixelach) bezstratna kompresja graficzna ma współczynnik kompresji zależny od danych, co przekłada się na różnice w czasie renderowania/zużyciu przepustowości – możliwe do pomiaru z aplikacji użytkownika.

Identyfikator CVE i metryki. CVE-2025-48561 opisuje ujawnienie informacji przez kanał boczny w wielu miejscach kodu, bez wymaganych dodatkowych uprawnień i bez interakcji użytkownika. NVD klasyfikuje ją obecnie (CVSS 3.x) jako MEDIUM 5.5 (ocena może ulec zmianie wraz z uzupełnieniem metadanych).

Łatki Google. Pierwsza zmiana ogranicza liczbę wywołań rozmycia (blur) akceptowanych przez system kompozytujący SurfaceFlinger („Don’t blur too many layers”, limit 10 „front-most” blurów). Badacze wskazują jednak, że znaleźli obejście – szczegóły pod embargiem. Kolejne poprawki zapowiedziano na grudzień 2025.

Praktyczne konsekwencje / ryzyko

  • Wykradanie kodów 2FA (TOTP) z aplikacji wyświetlających je wprost (np. Google Authenticator). To realnie obniża skuteczność MFA opartego wyłącznie na TOTP na podatnych urządzeniach.
  • Podgląd treści komunikatorów i e-maili, jeśli ekran aplikacji jest renderowany w momencie ataku.
  • Fingerprinting aplikacji zainstalowanych w systemie – badacze wskazują wektor ominięcia mechanizmów prywatności listy aplikacji (Google ocenił „won’t fix (infeasible)”).
  • Brak uprawnień → potencjalnie większa skala dystrybucji w razie pojawienia się malware’u wykorzystującego exploit (choć Google deklaruje, że na Play nie wykryto takich aplikacji).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SecOps / MDM (organizacje):

  1. Wymuś aktualizacje systemu – natychmiast instaluj poprawki z września 2025 i egzekwuj instalację po grudniowym biuletynie. Ustal wskaźniki zgodności (compliance) na poziomie floty.
  2. Tymczasowe zasady aplikacyjne:
    • Ogranicz użycie lokalnych aplikacji TOTP na urządzeniach o wysokim ryzyku; preferuj FIDO2/WebAuthn/klucze sprzętowe lub push-MFA z potwierdzeniem kontekstowym. (Wniosek na podstawie ryzyka opisanego przez badaczy).
    • W politykach EDR/MDM monitoruj nietypowe nakładanie Activities i intensywne wywołania blur (heurystyka na wzorzec PoC). (Wniosek na podstawie patcha i opisu ataku).
  3. Hardening przeglądarki/aplikacji biznesowych: Włączaj tryby ograniczające osadzanie (X-Frame-Options/CSP frame-ancestors) oraz przegląd konfiguracji Custom Tabs (np. Ephemeral Tabs, jeśli dostępne). (Kontekst badań „Tabbed Out”).

Dla deweloperów Android:

  • Minimalizuj ekspozycję wrażliwych danych na UI (maskowanie, ukrywanie kodów TOTP, skrócone okno wyświetlania). To nie eliminuje luki systemowej, ale zmniejsza powierzchnię ataku. (Wniosek na podstawie modelu wycieku pikseli).
  • Wykrywaj nakładki/„draw over” i nietypowe przełączanie się Activities nad Twoją aplikacją; w razie detekcji ukrywaj wrażliwe elementy UI. (Heurystyka defensywna wynikająca z opisu PoC).
  • Rozważ weryfikację kontekstu przed renderowaniem sekretów (np. wymuszenie interakcji, dodatkowy unlock, brak aktywnych nakładek). (Wniosek na podstawie wektora ataku).

Dla użytkowników:

  • Aktualizuj Androida jak tylko pojawi się poprawka; ogranicz instalację aplikacji spoza Google Play. Google deklaruje, że nie wykryto aplikacji wykorzystujących CVE-2025-48561 w Play.
  • Preferuj MFA odporne na podsłuch (klucze bezpieczeństwa/FIDO2) tam, gdzie to możliwe. (Rekomendacja wynikająca z natury ataku na TOTP).

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

  • Klasyczne ataki iframe/timing (2013) zostały w dużej mierze zmitigowane w przeglądarkach. Pixnapping wskrzesza ideę „kradzieży pikseli”, ale poza przeglądarką – na poziomie stosów UI Androida + kanału GPU.
  • GPU.zip (2023/2024) pokazał, że kompresja graficzna sama w sobie jest kanałem bocznym. Pixnapping wykorzystuje podobną obserwację, lecz łączy ją z nakładaniem Activities i blur API, co daje praktyczny wyciek z natywnych aplikacji mobilnych.

Podsumowanie / kluczowe wnioski

Pixnapping (CVE-2025-48561) to realny, choć niskoprzepustowy, wektor boczny na Androidzie, zdolny do kradzieży kodów 2FA i fragmentów danych aplikacji bez uprawnień. Częściowe łatanie po stronie Androida (limitowanie wywołań „blur”) nie zamyka jeszcze problemu – badacze wskazują obejście, a pełniejsze poprawki są w drodze. Organizacje powinny przyspieszyć patchowanie oraz ograniczyć zależność od TOTP na urządzeniach mobilnych wysokiego ryzyka, preferując FIDO2.

Źródła / bibliografia

  1. Strona projektu Pixnapping (paper, Q&A, timeline). (pixnapping.com)
  2. The Register: „Android ‘Pixnapping’ attack can capture app data like 2FA codes” (13.10.2025). (The Register)
  3. NVD: wpis CVE-2025-48561 (opis, metryki). (NVD)
  4. Android AOSP / googlesource: commit „Don’t blur too many layers” (ograniczenie wywołań blur). (Android Git Repositories)
  5. GPU.zip – strona i preprint (kanał boczny kompresji graficznej). (hertzbleed.com)

Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder”

Wprowadzenie do problemu

Hiszpańska Guardia Civil rozbiła działający na Telegramie i rosyjskojęzycznych forach syndykat cyberprzestępczy „GXC Team”, aresztując jego domniemanego lidera — 25-letniego Brazylijczyka znanego jako „GoogleXcoder”. Grupa sprzedawała w modelu Crime-as-a-Service (CaaS) zestawy phishingowe z funkcjami AI, złośliwe aplikacje na Androida do przechwytywania SMS/OTP oraz narzędzia do scamów głosowych. Celem były m.in. banki, firmy transportowe i e-commerce w Hiszpanii oraz innych krajach.

Czytaj dalej „Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder””