Archiwa: AI - Strona 48 z 49 - Security Bez Tabu

Tag: AI

Pracownicy wciąż obchodzą kontrolę dostępu. Nowy raport 1Password odsłania „luka zaufania do dostępu”

Wprowadzenie do problemu / definicja luki

1Password w najnowszym raporcie rocznym opisuje „Access-Trust Gap” – rosnącą różnicę między tym, co działy IT są w stanie kontrolować (SSO/IAM/MDM), a tym, jak faktycznie pracownicy i (coraz częściej) agenci AI uzyskują dostęp do danych i aplikacji. W praktyce oznacza to narastające „niewidzialne” logowania: do niezarządzanych aplikacji SaaS, z nieufnych urządzeń lub przy użyciu słabych poświadczeń.

W skrócie

  • 73% pracowników jest zachęcanych do używania AI, ale 37% przyznaje, że nie zawsze przestrzega polityk.
  • 52% pobrało aplikacje bez zgody IT (shadow IT/SaaS sprawl).
  • ~70% specjalistów bezpieczeństwa uważa, że SSO nie wystarcza do zabezpieczenia tożsamości.
  • 89% firm promuje passkeys jako krok w stronę ograniczenia ryzyka haseł.
  • BYOD i urządzenia prywatne podważają skuteczność klasycznego MDM.

Kontekst / historia / powiązania

Wyniki 1Password potwierdzają trend opisywany w prasie branżowej: rośnie skala shadow IT oraz „shadow AI” – pracownicy wybierają wygodę i szybkość kosztem nadzoru. Publikacje niezależne od producenta (HNS, Infosecurity) wskazują na podobne zachowania: obchodzenie polityk AI, instalowanie narzędzi bez akceptacji i użycie prywatnych urządzeń do pracy.

Analiza techniczna / szczegóły luki

AI & polityki

  • 94% deklaruje „przestrzeganie polityk AI”, ale tylko 37% robi to „przez większość czasu” – sygnał, że egzekwowanie i komunikacja reguł są słabe.

SaaS sprawl / shadow IT

  • 52% pracowników pobrało aplikacje bez zgody IT; offboarding bywa niespójny, bo znaczna część ekosystemu nie jest za SSO. Skutkiem są „martwe konta” i dostęp po odejściu z firmy.

Tożsamość i poświadczenia

  • Specjaliści bezpieczeństwa wskazują, że słabe/kompromitowane hasła pozostają kluczowym problemem; stąd szybka adopcja passkeys (89% firm zachęca do ich używania).

Urządzenia końcowe

  • MDM nie nadąża za hybrydową pracą i BYOD; wielu pracowników regularnie korzysta z prywatnych urządzeń do dostępu do danych firmy.

Praktyczne konsekwencje / ryzyko

  • Wycieki danych przez AI: wprowadzanie treści wrażliwych do niesankcjonowanych modeli i agentów.
  • Uporczywe „niezarządzane” logowania: aplikacje poza SSO/SCIM utrudniają detekcję, audyt i usuwanie dostępu.
  • Trwałość ryzyka haseł: współdzielenie/ponowne użycie haseł, phishing i infostealery.
  • Powierzchnia ataku BYOD: brak telemetryki i polityk bezpieczeństwa na urządzeniach prywatnych. W efekcie – dłuższy czas wykrycia i wyższy koszt incydentów.

Rekomendacje operacyjne / co zrobić teraz

  1. Rozszerz zarządzanie tożsamością poza SSO
    • Kataloguj wszystkie aplikacje (zarządzane i niezarządzane). Wdroż ciągłe odkrywanie SaaS i automatyczne przepływy aprowizacji/deprowizacji.
  2. Wprowadź politykę „approved AI” + kontrolę dostępu dla agentów
    • Zdefiniuj listę dozwolonych modeli/narzędzi AI, kanały wprowadzania danych i logging. Zamiast blokady – monitorowanie, DLP i tokenizacja.
  3. Przyspiesz przejście na passkeys
    • Używaj FIDO2/WebAuthn i kluczy sprzętowych/biometrii w miejscach wysokiego ryzyka; ogranicz manualną obsługę haseł przez użytkowników.
  4. BYOD z atrybucją zaufania urządzenia
    • Uzupełnij MDM o weryfikację stanu urządzenia (device trust), izolację danych (konteneryzacja), oraz warunkowy dostęp (per-app VPN, posture checks).
  5. Program higieny haseł i sekretów
    • Menedżer haseł/sekretów, rotacje, skan wycieków, zakaz udostępniania poza dedykowanymi „vaultami”.
  6. Twarde procedury offboardingu
    • Pełna lista aplikacji (także poza SSO), odzyskanie kluczy API i tokenów, zamknięcie kont federacyjnych oraz kont lokalnych.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do klasycznych raportów o „zmęczeniu hasłem” czy samym phishingu, 1Password skupia się na systemowym charakterze luki: rozjazd między narzędziami kontroli (SSO/MDM/IAM) a rzeczywistością pracy (SaaS, BYOD, AI). Niezależne materiały branżowe potwierdzają ten kierunek – problemem nie jest pojedyncza technika ataku, lecz operacyjna niewidoczność dostępu.

Podsumowanie / kluczowe wnioski

  • „Luka zaufania do dostępu” nie wynika z jednego błędu, tylko z kumulacji: SaaS sprawl + BYOD + AI + hasła.
  • Strategia powinna iść w stronę context-aware access: widoczność wszystkich aplikacji, polityki dla AI, passkeys, oraz device trust wykraczający poza klasyczny MDM.
  • Zamiast zakazów – prowadzenie i egzekwowanie: widzieć, rozumieć i automatyzować.

Źródła / bibliografia

  • Help Net Security: „Employees keep finding new ways around company access controls” (03.11.2025). (Help Net Security)
  • 1Password – The Access-Trust Gap: 2025 Annual Report (PDF).
  • 1Password – Komunikat prasowy (zestawienie kluczowych statystyk). (1password.com)
  • Infosecurity Magazine – omówienie „shadow AI” w firmach. (Infosecurity Magazine)
  • Expert Insights – podsumowanie wyników i metodyki badania. (Expert Insights)

PhantomRaven zalewa npm pakietami kradnącymi dane logowania. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Aktywna kampania PhantomRaven celuje w programistów ekosystemu JavaScript, publikując dziesiątki złośliwych paczek w rejestrze npm. Ich celem jest kradzież tokenów uwierzytelniających (npm, GitHub Actions, GitLab, Jenkins, CircleCI), sekretów CI/CD oraz poświadczeń do repozytoriów, co otwiera drogę do wtórnych ataków na łańcuch dostaw oprogramowania. Kampania rozpoczęła się w sierpniu 2025 r., obejmuje 126 paczek i przekroczyła 86 000 pobrań. Zidentyfikowali ją badacze Koi Security; część paczek w momencie publikacji raportów była wciąż dostępna w npm.

W skrócie

  • Skala: 126 złośliwych paczek, >86 000 pobrań (sierpień–październik 2025).
  • Technika ukrycia: Remote Dynamic Dependencies (RDD) – paczki deklarują 0 zależności, a właściwy ładunek dociągają z zewnętrznego serwera podczas npm install.
  • Egzekucja: wykorzystanie skryptów lifecycle (np. preinstall) do automatycznego uruchomienia payloadu bez interakcji użytkownika.
  • Kradzione dane: tokeny npm/GitHub/GitLab/Jenkins/CircleCI, fingerprinting systemu i środowiska CI/CD, adresy e-mail.
  • Exfiltracja: redundancja kanałów (HTTP GET z danymi w URL, HTTP POST/JSON, WebSocket).
  • Socjotechnika nazw: slopsquatting – wykorzystywanie halucynacji LLM do rejestrowania nieistniejących, lecz „wiarygodnie brzmiących” nazw paczek.

Kontekst / historia / powiązania

Ukrywanie złośliwego kodu w pakietach open source nie jest nowe, jednak PhantomRaven łączy kilka trendów: nadużycie rzadko używanej funkcji npm (URL-owe specyfikatory zależności), automatyczne skrypty instalacyjne i LLM-asystowanych rekomendacji paczek. Media branżowe opisują to jako ataki z „niewidzialnymi zależnościami”, które omijają statyczne skanery rejestrów i klasyczne analizatory SBOM.

Analiza techniczna / szczegóły luki

Remote Dynamic Dependencies (RDD)

Zamiast standardowych wpisów w "dependencies", złośliwe paczki wskazują HTTP URL (np. http://packages.storeartifact.com/...). Taki komponent nie znajduje się w npmjs.com, więc wiele narzędzi SCA/SAST go nie analizuje – interfejs npm pokazuje „0 dependencies”, co uśpiwa czujność. Podczas npm install pobierany jest zdalny pakiet, który zawiera preinstall uruchamiający złośliwy kod.

Łańcuch ataku

  1. Deweloper instaluje pozornie czystą paczkę z npm.
  2. Npm dociąga „niewidzialną” zależność z kontrolowanego przez atakującego hosta.
  3. Skrypt preinstall uruchamia się automatycznie, bez pytań.
  4. Malware wykonuje profilowanie systemu, enumerację e-maili i zbieranie sekretów CI/CD.
  5. Dane są eksfiltrowane wieloma kanałami (GET/POST/WebSocket).

Cele i techniki zbierania danych

  • Tokeny: npm, GitHub Actions, GitLab CI, Jenkins, CircleCI.
  • Fingerprinting: IP publiczny i lokalny, hostname, OS, wersja Node.js, bieżący katalog.
  • Artefakty identyfikacyjne: adresy e-mail z env, .gitconfig, .npmrc, package.json.

Infrastruktura i IoC

  • Domena/C2: packages.storeartifact.com
  • IP: 54.173.15.59
  • Endpoint exfiltracyjny: jpd.php
  • Wzorce kont/e-maili publikujących: jpdtester0X@..., m.in. jpdtester07@outlook[.]com, jpdtester12@gmail[.]com itd.
  • Przykładowe nazwy paczek: unused-imports, eslint-comments, transform-react-remove-prop-types, @gitlab-lsp/*, artifactregistry-login, crowdstrike, react-async-component-lifecycle-hooks, syntax-dynamic-import i wiele innych (pełna lista w raporcie Koi).

Slopsquatting (LLM-assisted naming)

Atakujący rejestrują nieistniejące wcześniej, lecz „wiarygodne” nazwy, które LLM potrafią podpowiadać jako rzekomo właściwe („unused-imports” vs. prawidłowe eslint-plugin-unused-imports, itp.). To omija proste reguły typosquattingu i zwiększa skuteczność socjotechniki wobec developerów polegających na asystentach AI.

Praktyczne konsekwencje / ryzyko

  • Przejęcie pipeline’ów i możliwość dorzucenia złośliwych commitów/releasów (supply-chain).
  • Kradzież sekretów skutkująca lateral movement do chmur, rejestrów artefaktów i środowisk produkcyjnych.
  • Trudna detekcja w klasycznych skanerach – ładunek nie jest obecny w artefakcie z npm, a zależności wyglądają na puste.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa reakcja (IR):

  1. Blokada IoC: zablokuj packages.storeartifact.com i powiązane IP na egressie; monitoruj ruch HTTP/WS do niezatwierdzonych hostów.
  2. Hunting: przeszukaj logi o instalacjach paczek z listy Koi; sprawdź wywołania npm install z nietypowymi URL-ami w package.json/package-lock.json.
  3. Rotacja sekretów: unieważnij tokeny npm/GitHub/GitLab/Jenkins/CircleCI, klucze API i hasła; wymuś ponowną autoryzację runnerów/agentów.
  4. Przegląd repozytoriów: audit ostatnich commitów/tagów/CI workflows pod kątem nieautoryzowanych zmian.

Twardnienie (hardening) na przyszłość:

  • Wyłącz skrypty lifecycle podczas CI: uruchamiaj npm ci z --ignore-scripts (lub npm config set ignore-scripts true w pipeline’ach, a w razie potrzeby whitelistuj pojedyncze przypadki). Uzupełnij o izolację sieciową stepów instalacyjnych. (Zasada wynika z analizy mechanizmu preinstall.)
  • Blokada zależności z URL: polityki DevSecOps/SCA powinny odrzucać HTTP(S) dependencies w package.json. Monitoruj PR-y pod kątem zmian w sekcji dependencies/scripts.
  • Wymuś 2FA i OIDC-based tokens dla dostępu do rejestrów/kont CI/CD; minimalne uprawnienia i krótkie TTL tokenów.
  • SBOM + detekcja behawioralna: klasyczny SBOM nie pokaże RDD; uzupełnij go o dynamiczną analizę instalacji (wykrywanie połączeń sieciowych podczas npm install).
  • Repozytoria lustrzane/air-gap: rozważ wewnętrzne mirrorowanie uznanych paczek i blokadę instalacji z internetu w CI (allowlist).
  • Edukacja dot. LLM: wprowadź guideline’y nt. weryfikacji nazw paczek sugerowanych przez AI; wymagaj sprawdzenia istnienia i reputacji projektu.

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

  • Klasyczny typosquatting: złośliwy kod siedzi w paczce na rejestrze; tutaj kod jest poza rejestrem (RDD), więc omija wiele skanerów.
  • Kampanie 2023–2025 (npm/PyPI) nierzadko używały postinstall do exfiltracji; PhantomRaven dodaje „niewidzialne” zależności i slopsquatting, co utrudnia detekcję i zwiększa skuteczność dystrybucji.

Podsumowanie / kluczowe wnioski

PhantomRaven pokazuje, jak łatwo połączyć niszowe funkcje npm, automatyczne skrypty instalacyjne i błędy poznawcze (zaufanie do LLM) w skuteczny atak na łańcuch dostaw. Krytyczne są: blokada HTTP-owych zależności, wyłączenie skryptów lifecycle w CI, rotacja i krótkie TTL tokenów, monitoring ruchu podczas instalacji oraz dyscyplina weryfikacji paczek – szczególnie tych „poleconych” przez asystentów AI.

Źródła / bibliografia

  1. BleepingComputer — PhantomRaven attack floods npm with credential-stealing packages (29 paź 2025). (BleepingComputer)
  2. Koi Security — PhantomRaven: NPM Malware Hidden in Invisible Dependencies (paź 2025) — szczegóły RDD, IoC i lista paczek. (Koi)
  3. Dark Reading — Malicious NPM Packages Disguised With ‘Invisible’ Dependencies (29 paź 2025) — omówienie techniki i kontekstu. (SCM Demo)
  4. Phylum — Sensitive Data Exfiltration Campaign Targets npm and PyPI (26 wrz 2023) — wcześniejsze, pokrewne kampanie exfiltracyjne. (blog.phylum.io)

TEE.Fail: nowy atak, który podważa „confidential computing” na CPU Intela, AMD i w ekosystemie GPU NVIDIA

Wprowadzenie do problemu / definicja luki

Zespół badaczy z Georgia Tech i Purdue przedstawił technikę TEE.Fail, która z użyciem taniego (≈< 1000 USD) interposera magistrali DDR5 pozwala odczytywać tajemnice z TEE (Trusted Execution Environment) nowej generacji – m.in. Intel TDX/SGX oraz AMD SEV-SNP (nawet z włączonym Ciphertext Hiding). Co więcej, wykradzione klucze atestacyjne umożliwiają podszywanie się pod zaufane środowiska i podważają modele zaufania także w GPU Confidential Computing NVIDII (np. H100).

W skrócie

  • Vektor ataku: pasywny podsłuch ruchu pamięci DDR5 z interposerem; brak potrzeby modyfikacji danych w locie.
  • Słaby punkt: deterministyczne szyfrowanie pamięci TEE (ta sama dana → ten sam szyfrogram), co umożliwia korelację wzorców i ekstrakcję kluczy.
  • Skutki: kradzież kluczy ECDH i kluczy atestacyjnych TDX/SGX, fałszowanie atestacji (także dla GPU-CC NVIDII), uruchamianie zadań poza TEE przy „zielonej” atestacji.
  • Koszt/próg wejścia: komponenty „z półki”, całość < 1000 USD.
  • Status vendorów: Intel potwierdził badania i utrzymuje, że ataki fizyczne pozostają poza modelem zagrożeń dla SGX/TDX; publikacja ogłoszenia bezpieczeństwa 28 października 2025 r.

Kontekst / historia / powiązania

TEE.Fail to następca ataków WireTap i Battering RAM, które dotyczyły DDR4 oraz starszych platform (gł. SGX/SEV bez DDR5). Kluczowa różnica: pierwsza demonstracja praktycznej skuteczności na DDR5 oraz CVM (Confidential VMs) opartych o Intel TDX i AMD SEV-SNP – czyli rozwiązania stanowiące fundament współczesnych wdrożeń „confidential computing”.

Analiza techniczna / szczegóły luki

Interposer DDR5. Badacze zbudowali interposer podpinany do jednego kanału DDR5 DIMM (DDR5 ma dwa kanały na moduł, co upraszcza konstrukcję) i pasywnie przechwytywali cały ruch DRAM między CPU a pamięcią. Zapis/odczyt są widoczne nawet przy szyfrowaniu pamięci przez TEE.

Szyfrowanie deterministyczne. SGX/TDX oraz SEV-SNP używają trybów szyfrowania pamięci, które w praktyce są deterministyczne (identyczny plaintext → identyczny ciphertext w tej samej lokalizacji). To umożliwia budowę słowników i korelację wzorców; na ilustracjach badaczy różnica między prawidłowym szyfrowaniem a deterministycznym jest wyraźna.

Ekstrakcja i fałszowanie atestacji (Intel). Z przechwyconych śladów udało się pozyskać Provisioning Certification Key – per-CPU klucz z łańcucha zaufania SGX/TDX. Mając go, atakujący fałszuje raporty atestacyjne i może uruchamiać obciążenia poza TEE, a jednak przekonać systemy, że działają w zaufanym CVM (nawet na innej architekturze CPU). Intel potwierdza i podkreśla, że fizyczne interposery są out-of-scope dla modelu zagrożeń TDX/SGX.

AMD SEV-SNP z Ciphertext Hiding. Badacze pokazali, że ataki działają nawet przy aktywnym Ciphertext Hiding (Zen 5/EPYC 5. gen), a więc mimo ograniczania widoczności szyfrogramów przez hypervisor. Dodatkowo zademonstrowano ekstrakcję kluczy podpisu OpenSSL wewnątrz VM chronionej przez SEV-SNP.

GPU Confidential Computing (NVIDIA). Ponieważ GPU-CC NVIDII opiera się na atestacji CVM CPU (TDX/SEV-SNP), przejęcie/wyłudzenie kluczy atestacyjnych CPU pozwala „pożyczać” atestacje GPU i prezentować zadania AI jako uruchomione w zabezpieczonym środowisku, choć faktycznie tak nie jest. To łamie model zaufania dla zadań AI (np. chaty LLM, inferencja modeli) na H100.

Praktyczne konsekwencje / ryzyko

  • Chmura/CVM: dostawca z dostępem fizycznym do serwera może podsłuchiwać i fałszować atestacje, wynosząc dane/klucze bez wykrycia z poziomu software’u.
  • Blockchain/MEV: demonstracja fałszowania atestacji TDX w sieci BuilderNet (Ethereum block builders), otwierająca drogę do niejawnego frontrunningu i dostępu do poufnych transakcji.
  • AI/LLM-as-a-Service: możliwość „udowodnienia” GPU-CC przy realnym uruchomieniu poza TEE → ryzyko wycieku danych treningowych/kluczy API i manipulacji wynikiem.
  • Szeroki ekosystem TEE: Intel oficjalnie klasyfikuje interposery jako poza modelem zagrożeń, co oznacza, że brak łatwych łatek firmware’owych – konieczne będą zmiany w założeniach architektonicznych i procesach operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

  1. Modeluj zagrożenia z fizycznym dostępem – jeśli Twoje ryzyko obejmuje atakującego z dostępem do szafy serwerowej, nie zakładaj, że TDX/SEV-SNP w DDR5 zapewnią pełną poufność. Zaktualizuj oceny ryzyka i umowy z operatorami DC/colocation.
  2. Zarządzaj zaufaniem do atestacji – wiąż atestacje z tożsamością sprzętu i lokalizacją (asset-binding), wdrażaj policyjne listy dozwolonych hostów, łącz atestację z kontrolą łańcucha dostaw/IMD i monitoringiem fizycznym.
  3. Segmentuj dane wrażliwe – minimalizuj ekspozycję tajemnic w TEE (krótkotrwałe klucze, HSM/KMS poza hostem, dzielone sekrety). Dla AI rozważ prywatność po stronie klienta/lokalne szyfrowanie przed wysłaniem do chmury. (Wnioski operacyjne na bazie skutków TEE.Fail).
  4. Twarde kontrole fizyczne – plombowanie, CCTV, ewidencja serwisantów, detection-by-presence (wykrywanie rozpięcia DIMM/risera). (Wnioski operacyjne wynikające z wektora ataku).
  5. Śledź komunikaty vendorów – Intel opublikował ogłoszenie bezpieczeństwa (28.10.2025). Monitoruj zapowiedziane stanowiska AMD i NVIDII dot. dostosowań modelu zagrożeń/mitigacji.
  6. Architektura „defense-in-depth” – TEE traktuj jako warstwę, nie jedyne zabezpieczenie. Odnów procedury DLP, EDR w hipervisorze, izolację sieciową CVM i kontrole dostępu do danych w spoczynku. (Dobre praktyki ogólne poparte kontekstem NCSC).

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

  • WireTap/Battering RAM (DDR4): atak na starszą generację pamięci/CPU; TEE.Fail eskaluje do DDR5 i CVM (TDX/SEV-SNP), co uderza w aktualne wdrożenia chmurowe.
  • RMPocalypse (CVE-2025-0033, AMD SEV-SNP): błąd inicjalizacji RMP łamie integralność VMs; TEE.Fail to atak fizyczny/side-channel na poufność + atestację. Razem pokazują, że zarówno błędy implementacji, jak i założenia modelu zagrożeń osłabiają dzisiejsze TEE.

Podsumowanie / kluczowe wnioski

TEE.Fail nie jest „kolejną” podatnością z CVE, lecz uderzeniem w fundamenty zaufania do confidential computing w epoce DDR5. Przy fizycznym dostępie do serwera i deterministycznym szyfrowaniu pamięci, granice TEE znikają: można wyciągnąć klucze, fałszować atestacje i obchodzić GPU-CC. Organizacje muszą przewartościować model zagrożeń, twardo kontrolować fizyczny dostęp oraz wiązać atestację ze sprzętem i lokalizacją. Krótkoterminowo – operacyjne obejścia i polityki; długoterminowo – zmiany w projektach szyfrowania pamięci i łańcuchach atestacji.

Źródła / bibliografia

  • Strona badaczy: TEE.fail – Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (FAQ, scenariusze ataku, skutki, mitgacje). (tee.fail)
  • Intel Security Announcement 2025-10-28-001 (TEE.fail) – stanowisko Intela i zakres modeli zagrożeń. (Intel)
  • BleepingComputer: „TEE.Fail attack breaks confidential computing on Intel, AMD, NVIDIA CPUs” – przegląd skutków i demonstracji (BuilderNet, fałszywe atestacje, wyciek ECDH). (BleepingComputer)
  • The Hacker News: „New TEE.Fail Side-Channel Attack Extracts Secrets from Intel and AMD DDR5 Secure Enclaves” – kontekst kosztu sprzętu i nowości względem DDR4. (The Hacker News)
  • NCSC (Szwajcaria): „Technology brief: Confidential Computing” – tło i modele TEE/CVM dla zrozumienia wpływu TEE.Fail. (ncsc.admin.ch)

ChatGPT Atlas: luka w „omniboxie” pozwala na jailbreaky i nadużycia agentów

Wprowadzenie do problemu / definicja luki

Badacze z NeuralTrust opisali nową technikę ataku na przeglądarkę ChatGPT Atlas, w której złośliwy ciąg wygląda jak adres URL, ale jest celowo sformatowany niepoprawnie. Atlas traktuje taki input w pasku adresu („omnibox”) najpierw jak URL, a gdy walidacja nawigacji zawodzi, degraduje go do polecenia tekstowego – jednak z wyższym zaufaniem i słabszymi kontrolami, co umożliwia cichy jailbreak i przejęcie zachowania agenta.

OpenAI w materiałach o Atlasie podkreśla, że bezpieczeństwo agentów było priorytetem – jednak opisana technika pokazuje, że granica między „zaufaną” intencją użytkownika a nieufnym inputem bywa w praktyce rozmyta.

W skrócie

  • Wejście przypominające URL wklejone do omniboxa może zostać potraktowane jako wysokozaufany prompt, jeśli nie przejdzie walidacji URL.
  • To pozwala omijać warstwy ochronne i wymuszać działania agenta (np. phishing, destrukcyjne operacje na kontach w chmurze).
  • Luka wpisuje się w szerszą klasę zagrożeń prompt injection dla „agenticznych” przeglądarek (Atlas, Comet, itp.).

Kontekst / historia / powiązania

Badania Brave pokazały systemowe problemy pośredniego prompt injection w przeglądarkach z agentami – złośliwe instrukcje mogą być ukryte nie tylko w tekście strony, lecz nawet w obrazach/screenshotach. Dyskusja ta rozgorzała w tym samym tygodniu, w którym zadebiutował Atlas.

Media branżowe i technologiczne zwracały uwagę na nowe wektory ryzyka wynikające z możliwości działania w imieniu użytkownika (dostępy do zalogowanych serwisów, historii, plików).

Analiza techniczna / szczegóły luki

NeuralTrust opisuje łańcuch zdarzeń:

  1. Przygotowanie ładunku – ciąg zaczyna się jak URL („https:” + domenopodobny fragment), ale zawiera język naturalny z imperatywami („follow these instructions…”) i celowe błędy (spacje, znaki, literówki).
  2. Wyzwolenie – użytkownik kopiuje/wkleja „link” do omniboxa (np. po kliknięciu „Copy link”).
  3. Iniekcja – walidacja URL nie przechodzi; Atlas traktuje treść jako prompt o pochodzeniu „od użytkownika”, z mniejszą liczbą kontroli.
  4. Eksploatacja – agent wykonuje instrukcje: od otwarcia fałszywego Google (phishing) po operacje na Google Drive (np. kasowanie plików) przy użyciu sesji uwierzytelnionej użytkownika.

SecurityWeek streszcza ten sam mechanizm i podaje przykładowy „URL-prompt”, ilustrując eskalację zaufania wynikającą z błędu parsowania pomiędzy trybem „Nawiguj” a „Zapytać/Wykonaj”.

Praktyczne konsekwencje / ryzyko

  • Phishing i kradzież sesji/poświadczeń poprzez otwieranie stron podszywających się pod zaufane serwisy.
  • Operacje krzyżodomenowe w kontekście zalogowanego użytkownika (np. Drive, poczta) – tradycyjne SOP/CSRF nie chronią przed intencją agenta.
  • Degradacja polityk bezpieczeństwa (RL, guardraily) – prompt traktowany jako „intencja” może ominąć filtry treści.

Szerszy ekosystem agentów przeglądarkowych już wcześniej wykazał podatność na injection (w tym z obrazów), co dowodzi, że to problem systemowy, a nie pojedynczy bug.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników końcowych (od razu):

  • Nie wklejaj do omniboxa „linków” z nieznanych źródeł; traktuj przycisk „Copy link” jak potencjalny wektor ataku.
  • Wyłącz/ogranicz automatyczne akcje agenta i wymagaj potwierdzenia przed dostępem do poczty, dysków, formularzy płatniczych.
  • Oddziel przeglądanie wrażliwe (bankowość, praca) od eksperymentów z agentem (np. osobny profil/konto).

Dla zespołów SecOps/AppSec (krótkoterminowo):

  • W politykach EDR/DLP i proxy oznaczaj ruch Atlas oraz monitoruj anomalie na kontach SaaS (Drive, O365).
  • Wprowadź kontrole kontekstowe (step-up MFA, reautoryzacja narzędzi) przy akcjach inicjowanych przez agentów.
  • Edukuj użytkowników: „URL ≠ URL” – pokaż przykłady obfuskacji i mechanizm degradacji do promptu. (na bazie case’u NeuralTrust).

Dla vendorów/pracujących nad agentami (średnioterminowo):

  • Twarde parsowanie i normalizacja URL; jeśli są niejednoznaczności – odrzuć, bez cichego fallbacku do trybu prompt.
  • Jawny wybór trybu (Navigate vs Ask/Act) i widoczny stan UI; brak automatycznych przełączeń.
  • Zasada najmniejszych uprawnień dla promptów z omniboxa; potwierdzenie użytkownika przy narzędziach/akcjach krzyżodomenowych.
  • Stripping instrukcji z inputów „URL-opodobnych” i tagowanie pochodzenia tokenów w rozmowie z LLM.

Różnice / porównania z innymi przypadkami

  • Comet / „niewidzialne” injekcje w obrazach: wektor to kontekst strony/screenshot, a nie omnibox; w Atlasie wektor siedzi w pasku adresu i podszywa się pod intencję użytkownika.
  • Klasyczne XSS/CSRF: atak nie łamie przeglądarkowego SOP – agent wykonuje akcje „w dobrej wierze”, co omija wiele klasycznych barier. (por. szersze omówienie w The Register i literaturze nt. agentów webowych).

Podsumowanie / kluczowe wnioski

  • Luka w omniboxie Atlasu to błąd granicy zaufania: URL-opodobny ciąg staje się wysokozaufanym promptem.
  • Efekt: jailbreaky i aktywne nadużycia w kontekście zalogowanego użytkownika.
  • Rozwiązania: twarde parsowanie, jawne tryby, potwierdzenia i proweniencja tokenów – do wdrożenia zarówno po stronie vendorów, jak i w politykach organizacji.

Źródła / bibliografia

  • NeuralTrust: „OpenAI Atlas Omnibox Prompt Injection: URLs That Become Jailbreaks” (24 paź 2025). (NeuralTrust)
  • SecurityWeek: „OpenAI Atlas Omnibox Is Vulnerable to Jailbreaks” (25 paź 2025). (SecurityWeek)
  • OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta. (OpenAI)
  • Brave: „Unseeable prompt injections… more vulnerabilities in Comet and other AI browsers”. (Brave)
  • The Register: „OpenAI defends Atlas as prompt injection attacks surface”. (The Register)

3 000 filmów na YouTube jako pułapki malware. „YouTube Ghost Network” rozbite — co to było i jak się bronić

Wprowadzenie do problemu / definicja luki

Check Point Research ujawnił skoordynowaną operację dystrybucji złośliwego oprogramowania na YouTube, nazwaną YouTube Ghost Network. Sieć wykorzystywała przejęte lub fałszywe konta, by publikować filmy-tutoriale (cracki, „haki” do gier), które prowadziły do pobrania stealerów informacji. Zidentyfikowano ponad 3 000 złośliwych filmów, z których wiele miało setki tysięcy wyświetleń. Po zgłoszeniach badaczy Google usunął większość treści. Źródło przypisuje aktywność co najmniej od 2021 r., a w 2025 r. liczba filmów potroiła się.

W skrócie

  • Skala: >3 000 filmów na przejętych kanałach; rekordowe pojedyncze wideo ~293 tys. wyświetleń (Photoshop), inne ~147 tys. (FL Studio).
  • Wektor socjotechniczny: „darmowe” cracki i cheaty (m.in. Roblox, Adobe, FL Studio), komentarze i lajki budujące fałszywą wiarygodność.
  • Rodziny malware: głównie infostealery – Lumma (przed jej wiosennym rozbiciem), później Rhadamanthys, a także RedLine, StealC, Phemedrone/0debug; bywał łańcuch z HijackLoaderem.
  • Łańcuch infekcji: linki w opisie, przypiętych komentarzach lub „instrukcji wideo” → skracacze URL → Google Sites/Blogger/Telegra.ph lub dyski Dropbox/Google Drive/MediaFire → archiwum z hasłem + prośba o wyłączenie Defendera → payload.
  • Reakcja branży: Check Point + Google usunęli większość treści; media branżowe potwierdziły skalę i modus operandi.

Kontekst / historia / powiązania

  • Lumma Stealer był „hitem” w sieci do czasu międzynarodowej akcji Microsoftu i Europolu (16 marca–16 maja 2025 r.), po której operatorzy kampanii częściej przechodzili na Rhadamanthys.
  • Zjawisko „Ghost Network” wcześniej opisywano na GitHubie (kampania Stargazers Ghost Network), gdzie masowo podszywano się pod wiarygodne repozytoria do dystrybucji złośliwych plików. YouTube to kolejna odsłona tej samej taktyki „platform-as-distribution”.

Analiza techniczna / szczegóły luki

Architektura ról (operacja na YouTube):

  1. Video-accounts – publikują filmy-wabiki i udostępniają linki (w opisie, przypiętym komentarzu lub jako „hasło+link” w samym wideo).
  2. Post-accounts – publikują posty społeczności z linkami i hasłami do archiwów; aktualizują wpisy, by omijać zgłoszenia; możliwe użycie AI do interakcji.
  3. Interact-accounts – dodają „lajki” i entuzjastyczne komentarze („works!”, „no virus”), podbijając sygnały zaufania.

Łańcuch dystrybucji i unikanie detekcji:

  • Skracacze URL maskujące destynację.
  • Hosty plików i usługi Google (Sites/Blogspot/Drive) – wysoka reputacja domen utrudnia filtrowanie reputacyjne.
  • Archiwa chronione hasłem (często „1337”) – brak możliwości skanowania zawartości bez hasła.
  • Instrukcje „wyłącz Defendera na chwilę” – celowe osłabienie ochrony podczas instalacji.
  • Pliki o dużych rozmiarach lub MSI instalujące HijackLoadera, który dociąga właściwy stealer (np. Rhadamanthys).

Cele i treści przynęt:

  • Cracki do Adobe Photoshop/Premiere/Lightroom, FL Studio, CorelDRAW, cheaty do gier (np. Roblox).
  • Kierowanie do grup docelowych (twórcy wideo/muzyki, gracze), gdzie popyt na „darmowe” narzędzia jest wysoki.

Praktyczne konsekwencje / ryzyko

  • Utrata danych uwierzytelniających (przeglądarki, menedżery haseł, cookie session tokens), portfele kryptowalut, poczta i konta społecznościowe — typowe dla stealerów.
  • Przejęcia kont korporacyjnych przez wykradzione sesje (SSO, M365, Slack, Git).
  • Wektory wtórne: zainfekowane endpointy stają się punktem wyjścia do BEC, ransomware lub dalszych kradzieży danych. (Wynika z typowych zdolności Lumma/Rhadamanthys i obserwacji Check Point dot. infostealerów w kampanii).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT (organizacje)

  1. Zablokuj ryzykowne kategorie transferów: egzekwuj polityki dla popularnych skracaczy URL i hostingów plików (Dropbox/Drive/MediaFire) w ruchu korporacyjnym — co najmniej kontrola i logowanie + izolacja przeglądarkowa dla niezweryfikowanych pobrań.
  2. Reguły detekcji:
    • Alerty na pobrania archiwów z hasłem z przeglądarki i nietypowe uruchomienia msiexec/exe po pobraniu.
    • Telemetria EDR dla wskaźników typowych dla Rhadamanthys/Lumma (procesy z nietypową komunikacją C2, kradzież danych z przeglądarek). (Uzasadnienie: kampania dostarczała właśnie te stealer-y).
  3. Zasady anty-tampering: wymuś niemożność wyłączenia Defendera/AV przez użytkownika bez uprawnień admina; monitoruj zdarzenia prób wyłączenia ochrony w czasie instalacji.
  4. Twarde uwierzytelnianie: MFA odporne na phishing (FIDO2/Passkeys), krótkie TTL sesji, automatyczne unieważnianie tokenów po incydencie ze stealerem. (Kontekst: masowe kradzieże cookies przez stealery).
  5. Kontrola aplikacji i uprawnień: blokada uruchamiania niepodpisanych MSI/EXE spoza zaufanych katalogów; WDAC/AppLocker; zasada least privilege na endpointach.
  6. DTR/IR playbook dla stealerów: natychmiastowa rotacja haseł/kluczy/API, reset sesji, przegląd logowania z nowych lokacji, przegląd skrzynek i reguł przekierowań.

Dla użytkowników (awareness)

  • Nie instaluj cracków i „hacków do gier” — to w 2025 r. najczęstsza przynęta w tej kampanii.
  • Weryfikuj kanały i linki: jeśli link prowadzi przez skracacz lub na Google Sites/Telegra.ph i wymaga hasła do archiwum – traktuj to jako czerwone flagi.
  • Nie wyłączaj antywirusa „na chwilę” z powodu filmu w sieci.
  • Używaj menedżera haseł + MFA i aktualizuj system.

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

  • GitHub „Stargazers Ghost Network” (2024–2025) i YouTube Ghost Network (2025) to ta sama logika „Ghost accounts as a service” na różnych platformach: manipulacja sygnałami zaufania (gwiazdki/forciowanie repo vs. wyświetlenia/komentarze), treści przynęt (narzędzia/dev-tool vs. cracki/cheaty), lecz cel identyczny — masowa dystrybucja infostealerów przy użyciu „dobrych” domen i funkcji społecznościowych.

Podsumowanie / kluczowe wnioski

  • Kampania YouTube Ghost Network pokazała, jak łatwo zbrodnicze grupy weaponizują platformy społecznościowe — od SEO i komentarzy po posty społeczności — by sprzedawać wiarygodność i dostarczać malware na masową skalę.
  • Cracki i cheaty pozostają najbardziej ryzykownym typem treści dla użytkowników; to na nich żerują operatorzy stealerów.
  • Higiena tożsamości, polityki pobrań i kontrola aplikacji są dziś równie ważne, co sygnaturowe AV.
  • Po rozbiciu Lumma napastnicy przechodzą na alternatywy (Rhadamanthys), co wymaga ciągłej adaptacji detekcji.

Źródła / bibliografia

  • Check Point Research: Dissecting YouTube’s Malware Distribution Network (23 października 2025). (Check Point Research)
  • The Hacker News: 3,000 YouTube Videos Exposed as Malware Traps… (24 października 2025). (The Hacker News)
  • The Register: Google and Check Point nuke massive YouTube malware… (23 października 2025). (The Register)
  • Help Net Security: Researchers expose large-scale YouTube malware distribution network (23 października 2025). (Help Net Security)
  • Europol: Europol and Microsoft disrupt world’s largest infostealer Lumma (21 maja 2025). (Europol)

Hakerzy polują na użytkowników przeglądarki Perplexity Comet: fałszywe domeny, aplikacje i reklamy

Wprowadzenie do problemu / definicja luki

Krótko po premierze przeglądarki Perplexity Comet cyberprzestępcy uruchomili skoordynowaną kampanię podszywania się pod markę: rejestrowali domeny podobne do oficjalnych adresów, publikowali fałszywe aplikacje mobilne i promowali fikcyjne instalatory poprzez reklamy w wyszukiwarkach i mediach społecznościowych. Celem jest skłonienie użytkowników do pobrania nieautoryzowanego oprogramowania lub przeklikania się do stron phishingowych podszywających się pod „pobieranie Comet”. Takie wnioski opublikował zespół BforeAI, a temat opisał SecurityWeek.

W skrócie

  • Czas: Comet wystartował 9 lipca 2025 r.; 2 października 2025 r. został udostępniony bezpłatnie dla wszystkich. Kampania fałszywych domen i aplikacji nasiliła się między sierpniem a październikiem 2025 r.
  • Skala: BforeAI przeanalizowało >40 podejrzanych domen; część z nich to bezpośrednie imitacje marki (np. perplexitycomet-ai.com, cometaibrowser.com).
  • Aplikacje mobilne: wykryto krytyczne fałszywe pozycje w Google Play oraz nieautoryzowaną aplikację w App Store, przed którą publicznie ostrzegł CEO Perplexity.
  • Powiązane ryzyka: wcześniejsze badania wykazały, że AI-przeglądarki (w tym Comet) są podatne na prompt-injection, phishing i scenariusze „agentic”.

Kontekst / historia / powiązania

Perplexity uruchomiło Comet jako AI-native przeglądarkę z asystentem zintegrowanym w przepływ pracy (poczta, kalendarz, research). Początkowo dostęp był ograniczony, później – od 2 października – produkt stał się darmowy dla wszystkich użytkowników, co znacząco zwiększyło rozpoznawalność marki i… atrakcyjność dla oszustów.

Równolegle pojawiły się niezależne badania bezpieczeństwa: Guardio Labs pokazało scenariusz „Scamlexity”, w którym AI-przeglądarka potrafi zautomatyzować błędne działania (np. pomagać dokonać zakupu na fałszywym sklepie), a LayerX opisał technikę CometJacking, gdzie pojedynczy złośliwy URL „przejmuje” agenta i wykrada dane (e-maile, kalendarz, „pamięć” użytkownika).

Analiza techniczna / szczegóły kampanii podszywania się

Wektory ataku zidentyfikowane przez BforeAI:

  1. Typosquatting i brand impersonation — rejestracje po starcie Comet, z użyciem słów kluczowych „comet”, „ai”, „browser”, „perplexity”, „download”. Przykłady: cometai.site, cometaibrowser.com, perplexitycomet-ai.com, cometbrowser.net, aicometbrowser.com. Część domen parkowana (np. cometai.net oferowana za 9 999 $).
  2. SEO-poisoning / malvertising — reklamy w wyszukiwarkach i social media kierujące do „pobierania Comet” z nieoficjalnych stron trzecich; serwowane pseudo-instalatory EXE.
  3. Fałszywe aplikacje mobilne — m.in. „Comet AI Atlas App Info” w Google Play; dodatkowo nieautoryzowana pozycja w iOS App Store, przed którą ostrzegł publicznie CEO Perplexity 14 października 2025 r.

Cechy operacyjne kampanii: wykorzystanie prywatności WHOIS, rejestratorów w różnych jurysdykcjach (w tym REG.RU, Name SRS AB, NameCheap) i szybkich, niedrogich rejestracji TLD (.com, .net, .ai, .site, .app), co utrudnia egzekwowanie i sprzyja rotacji infrastruktur.

Praktyczne konsekwencje / ryzyko

  • Zainfekowanie endpointu przez pobranie nieoficjalnego instalatora (infostealery, adware, RAT) podszywającego się pod „Comet Setup”. (Wniosek na podstawie znanych TTP kampanii malvertising / fake installers).
  • Kradzież danych i sesji: w scenariuszu CometJacking samo odwiedzenie spreparowanego linku może wywołać działania agenta i eksfiltrację treści (e-maile, kalendarz, „memory”).
  • Utrata środków / phishing transakcyjny: „Scamlexity” pokazuje, że agent może „pomóc” dokończyć oszustwo, jeśli UX atakującego zostanie zaprojektowany pod AI.
  • Ryzyko reputacyjne i zgodności dla organizacji dopuszczających niezweryfikowane pobrania i korzystanie z nieoficjalnych aplikacji.

Rekomendacje operacyjne / co zrobić teraz

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

  1. Pobieraj Comet wyłącznie z oficjalnych kanałów Perplexity (witryna i wpisy na blogu produktu). Zweryfikuj domenę perplexity.ai i podpisy binariów.
  2. Ignoruj reklamy „Download Comet” w Google/Bing oraz „skróty” w social media — zamiast tego wpisz adres ręcznie. (Wniosek na podstawie analizy malvertisingu BforeAI).
  3. Na mobile: do czasu oficjalnej premiery iOS nie instaluj żadnej „Comet” z App Store; zgłaszaj podejrzane pozycje.
  4. Przeglądarka/agent – higiena bezpieczeństwa: wyłącz autowykonywanie wtyczek/akcji, ogranicz uprawnienia do skrzynek pocztowych i kalendarzy, używaj profili tymczasowych do zadań „agentic”. (Wniosek na podstawie CometJacking/Scamlexity).

Dla SOC/Blue Team

  1. Blokady DNS/URL: dodaj wykazane przez BforeAI wskaźniki (domeny typosquatting) do list blokad i monitoringu; śledź rejestracje z ciągami comet|perplexity|browser|ai.
  2. Polityka instalacji: wymuś allow-listę źródeł oprogramowania; blokuj instalatory z unknown publisher.
  3. Detekcje: reguły na ruch do nowych, świeżo zarejestrowanych domen + detekcja nietypowych zapytań HTTP/JS wskazujących na exfiltrację przez agenta (np. base64 w parametrach URL opisana przez LayerX).
  4. Awareness: przeszkol użytkowników nt. prompt-injection i ryzyk „agentic browsing”; pokaż realne dema (Scamlexity).

Różnice / porównania z innymi przypadkami

  • AI-native vs. klasyczne przeglądarki: kluczowa różnica to agent wykonujący akcje. W tradycyjnej przeglądarce ofiara musi kliknąć/ulegać socjotechnice; w AI-przeglądarce agent może zautomatyzować niepożądane decyzje. (Wniosek na podstawie Guardio/LayerX).
  • Powierzchnia ataku: poza phishingiem dochodzi manipulacja kontekstem (prompt-injection, data exfiltration z „pamięci” agenta), co zwiększa skutki błędu użytkownika.

Podsumowanie / kluczowe wnioski

  • Popularność Comet po udostępnieniu „dla wszystkich” zbiegła się z falą nadużyć marki (domeny, reklamy, aplikacje).
  • Zagrożenia „agentic” sprawiają, że koszt błędu użytkownika jest wyższy niż w klasycznych przeglądarkach. Zasada 0-zaufania do reklam i nieoficjalnych źródeł jest tu krytyczna.
  • Organizacje powinny wyprzedzić atakujących: blokady DNS, polityki instalacji, profile ograniczone dla AI-agentów, oraz bieżące śledzenie wskaźników BforeAI.

Źródła / bibliografia

  • SecurityWeek: Hackers Target Perplexity Comet Browser Users (24 paź 2025). (SecurityWeek)
  • BforeAI: Threat Research Report: Malicious Activity Surrounding Perplexity’s Comet Browser Launch (paź 2025). (BforeAI)
  • Perplexity Blog: Introducing Comet (9 lip 2025) i Comet is now available to everyone worldwide (2 paź 2025). (Perplexity AI)
  • Guardio Labs: “Scamlexity”: We Put Agentic AI Browsers to the Test (20 sie 2025). (Guard.io)
  • LayerX: CometJacking: How One Click Can Turn Perplexity’s Comet AI Browser Against You (paź 2025). (LayerX)

GlassWorm: samorozprzestrzeniający się robak infekuje rozszerzenia VS Code i uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa opisali nową kampanię malware nazwaną GlassWorm, która samodzielnie rozprzestrzenia się poprzez zainfekowane rozszerzenia Visual Studio Code publikowane w rejestrach Open VSX i Microsoft VS Code Marketplace. Atak celuje w łańcuch dostaw oprogramowania – wprost w narzędzia deweloperskie – kradnie poświadczenia (npm, GitHub), przejmuje środowiska i wykorzystuje maszyny programistów jako infrastrukturę przestępczą.

W skrócie

  • Skala: ok. 35,8 tys. instalacji złośliwych rozszerzeń; co najmniej kilka–kilkanaście paczek w obiegu w OpenVSX i na rynku Microsoftu.
  • Techniki ukrywania: „niewidzialny kod” z użyciem niewidocznych znaków Unicode w źródłach rozszerzeń, utrudniający przegląd i detekcję.
  • Zdolności: kradzież tokenów npm/GitHub, celowanie w 49 wtyczek portfeli krypto, uruchamianie SOCKS proxy i ukrytego VNC/RAT dla pełnego zdalnego dostępu.
  • Propagacja: użycie wykradzionych poświadczeń do publikowania zainfekowanych aktualizacji i przejmowania kolejnych kont/paczek.

Kontekst / historia / powiązania

Pierwsze publiczne raporty pojawiły się 20–24 października 2025 r.. Media branżowe i dostawcy bezpieczeństwa (m.in. BleepingComputer, Dark Reading) potwierdzają, że to jedna z najpoważniejszych jak dotąd kampanii wymierzonych w ekosystem VS Code. Część źródeł wiąże odkrycie z pracą badaczy Koi Security, a rozszerzenia w OpenVSX miały zostać podmienione 17 października; 2 dni później część z nich nadal rozprowadzała malware.

Analiza techniczna / szczegóły luki

Vektor wejścia. GlassWorm trafia do środowisk poprzez instalację (lub aktualizację) zainfekowanych rozszerzeń VS Code z OpenVSX oraz Microsoft Marketplace. Atakujący przejmują konta wydawców lub łańcuch CI/CD i publikują skażone wersje.

„Niewidzialny” kod. Krytycznym elementem jest ukrywanie złośliwej logiki z użyciem znaków sterujących Unicode (np. kierunków zapisu/bidirectional control), które sprawiają, że fragmenty kodu nie są widoczne przy zwykłym przeglądzie i mogą mylić zarówno recenzentów, jak i niektóre narzędzia SAST. Efekt: czysty diff, pozornie prawidłowa składnia, złośliwe ścieżki wykonania zaszyte między literami.

Zdolności po infekcji. Po zainstalowaniu, GlassWorm:

  • eksfiltruje poświadczenia npm i GitHub oraz inne sekrety deweloperskie,
  • skanuje przeglądarkę/środowisko pod kątem 49 rozszerzeń portfeli krypto i próbuje drenować środki,
  • wdraża SOCKS proxy, aby wykorzystywać hosta jako przekaźnik,
  • instaluje ukryte VNC/RAT dla pełnego zdalnego dostępu, utrzymując się w systemie,
  • używa skradzionych tokenów do przejęcia kolejnych pakietów/rozszerzeń i samoreplikacji.

Skala i telemetry. Według niezależnych relacji prasowych i firm badawczych mówimy o ~35,8 tys. instalacji/udanych pobrań skażonych rozszerzeń; atak dotknął co najmniej kilka–kilkanaście pakietów w popularnych rejestrach rozszerzeń.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: przejęte tokeny npm/GitHub = ryzyko publikacji trojanów w repozytoriach firmy/OSS.
  • Ryzyko finansowe: celowanie w portfele krypto i możliwa utrata środków.
  • Infrastruktura przestępcza: hosty dev stają się proxy i zdalnymi stacjami sterowanymi przez atakujących (VNC/RAT) – ekspozycja sieci wewnętrznej.
  • „Blind spot” w code review: użycie niewidzialnych znaków obchodzi kontrolę peer review i statyczną analizę, co utrudnia tradycyjne procesy SDLC.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (IR – Incident Response):

  1. Inwentaryzacja rozszerzeń VS Code w organizacji (OpenVSX/Microsoft Marketplace). Wytypować i odinstalować podejrzane/ostatnio aktualizowane.
  2. Rotacja i unieważnienie wszystkich tokenów npm/GitHub/PAT, kluczy CI/CD, cookies sesyjnych przeglądarki; włączyć 2FA i ograniczyć zakres uprawnień (fine-grained PAT).
  3. Izolacja stacji roboczych dev: odłączenie od sieci, skan EDR/AV, detekcja SOCKS proxy i ukrytych usług VNC/RAT; przegląd autostartów i harmonogramów zadań.
  4. Przegląd repozytoriów i rejestrów: niezwłoczne sprawdzenie ostatnich publikacji/commitów/wersji paczek pod kątem nietypowych zmian i „niewidzialnego” Unicode.

W kolejnych dniach (hardening):

  • Wymuś weryfikację wydawcy i pinning zaufanych rozszerzeń; ogranicz instalację do listy dozwolonych (allow-list). (Praktyka zalecana przez branżę w kontekście tego incydentu).
  • W pipeline’ach dodaj kontrole Unicode (detekcja znaków sterujących Bidi, zero-width, itd.) i policy skanów dla rozszerzeń/artefaktów przed dopuszczeniem do stacji dev.
  • Egzekwuj zasadę najmniejszych uprawnień dla tokenów (scopes, TTL, rotacja), ochronę sekretów i monitoring publikacji (alerty przy zmianie maintainerów lub kluczy publikacyjnych).
  • Użyj EDR z regułami na nietypowe połączenia proxy/VNC i anomalie narzędzi deweloperskich; przegląd ruchu wychodzącego pod kątem tuneli SOCKS.

Artefakty/detekcja (przykłady do playbooka IR):

  • Skan plików źródłowych pod kątem znaków: \u202E, \u2066–\u2069, \u200B itd. (Bidi/zero-width).
  • Audyt folderów rozszerzeń ~/.vscode/extensions / %USERPROFILE%\.vscode\extensions pod kątem niepodpisanych/nieznanych vendorów i recent-modified. (Dobre praktyki zgodne z doniesieniami o wektorze).

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

W porównaniu z wcześniejszymi incydentami „tylko” trojanizującymi pojedyncze rozszerzenie, GlassWorm łączy samopropagację (wykorzystanie świeżo wykradzionych tokenów do publikacji kolejnych zainfekowanych aktualizacji) z niewidzialnym kodem Unicode, co utrudnia review i automatyczną analizę. To jakościowy skok względem znanych kampanii typosquattingu i przejęć paczek NPM/VS Code.

Podsumowanie / kluczowe wnioski

  • GlassWorm uderza w samo serce SDLC – narzędzia deweloperskie – i omija klasyczne bramki kontrolne dzięki „niewidzialnym” trikom Unicode.
  • Organizacje powinny traktować sprawę jak incydent bezpieczeństwa łańcucha dostaw: natychmiastowa rotacja sekretów, czyszczenie stacji dev, whitelisting rozszerzeń i kontrole Unicode w pipeline’ach.
  • Nawet po usunięciu skażonych wtyczek, skradzione tokeny mogą umożliwiać dalsze nadużycia – higiena kluczy i monitoring publikacji są krytyczne.

Źródła / bibliografia

  • The Hacker News – „Self-Spreading ‘GlassWorm’ Infects VS Code Extensions…” (24 października 2025). (The Hacker News)
  • BleepingComputer – „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • Dark Reading – „Self-Propagating GlassWorm Attacks VS Code Supply Chain” (20 października 2025). (Dark Reading)
  • Truesec – „GlassWorm – Self-Propagating VSCode Extension Worm” (analiza techniczna, październik 2025). (Truesec)
  • Koi Security (blog) – przegląd zdolności GlassWorm i TTP (październik 2025). (koi.ai)