Archiwa: Phishing - Strona 200 z 207 - Security Bez Tabu

Tag: Phishing

ONZ przyjmuje „Hanoi Convention”: globalny traktat przeciw cyberprzestępczości otwarty do podpisu. Co to oznacza dla SOC-ów i compliance?

Wprowadzenie do problemu / definicja luki

25 października 2025 r. ONZ otworzyła w Hanoi do podpisu pierwszy globalny traktat przeciw cyberprzestępczości („UN Convention against Cybercrime”, nieformalnie: Hanoi Convention). Wydarzenie zgromadziło delegacje dziesiątek państw i ma usprawnić współpracę międzynarodową w sprawach takich jak phishing, ransomware, handel ludźmi online czy mowa nienawiści. Już podczas ceremonii podpisania dokument zyskał szerokie poparcie – choć towarzyszą mu poważne zastrzeżenia dotyczące praw człowieka i wolności badań bezpieczeństwa.

W skrócie

  • Status: traktat otwarty do podpisu 25 października 2025 r. w Hanoi; 65 państw podpisało w pierwszym dniu. Wejście w życie: po złożeniu 40 dokumentów ratyfikacyjnych. Okno podpisów pozostaje otwarte do 31 grudnia 2026 r.
  • Cel: ujednolicenie przestępstw, procedur dowodowych i kanałów współpracy transgranicznej w sprawach cyber.
  • Kto podpisuje: m.in. UE oraz państwa członkowskie (zgoda na podpis wyrażona wcześniej przez Radę UE).
  • Kontrowersje: branżowe porozumienie Cybersecurity Tech Accord (m.in. Microsoft, Meta) i organizacje praw człowieka ostrzegają przed ryzykiem nadużyć („traktat nadzoru”) i penalizacją etycznych badań.

Kontekst / historia / powiązania

Negocjacje konwencji prowadziło UNODC po latach dyskusji nad potrzebą globalnych, a nie tylko regionalnych (np. europejskich), ram walki z cyberprzestępczością. Sekretarz Generalny ONZ podkreślił koszt cyberprzestępczości liczony w „bilionach dolarów rocznie” i konieczność ułatwienia współpracy między organami ścigania.
Strona konwencji prowadzona przez UNODC potwierdza harmonogram: podpis w Hanoi, a następnie możliwość podpisywania w siedzibie ONZ w Nowym Jorku, z wejściem w życie 90 dni po 40. ratyfikacji.

Analiza techniczna / szczegóły traktatu

Choć pełny tekst jest obszerny, trzon instrumentu obejmuje trzy bloki, które mają największe znaczenie dla praktyków cyberbezpieczeństwa i zespołów prawnych:

  1. Katalog przestępstw – od oszustw (phishing), przez ataki z użyciem malware/ransomware, po przestępstwa związane z treścią (np. mowa nienawiści) definiowane według standardów ONZ. To rozszerzenie tradycyjnych ujęć „komputerowych” czynów zabronionych o kategorie, które w wielu jurysdykcjach są nadal rozproszone.
  2. Procedury dowodowe i e-dowody – zharmonizowane zasady zabezpieczania, utrwalania i udostępniania danych elektronicznych (logi, metadane, treści), ułatwiające szybką i zgodną z prawem wymianę materiału dowodowego między państwami. UNODC wskazuje, że konwencja ma promować „legalne badania” i zawiera klauzule ochrony praw człowieka.
  3. Współpraca transgraniczna – kanały pomocy prawnej, tryb „nagłych wniosków” i punkty kontaktowe 24/7, aby skrócić czas reakcji w incydentach transgranicznych. UE potwierdziła zamiar podpisu i wdrażania zgodnie z własnymi standardami praw człowieka.

Praktyczne konsekwencje / ryzyko

Dla firm (CISO, SOC, DPO):

  • Więcej wezwań międzynarodowych o dane: krótsze terminy na „preservation” i przekazanie logów/treści organom zagranicznym – zwłaszcza dla usług chmurowych i platform o zasięgu globalnym.
  • Zwiększona interoperacyjność procedur dowodowych – potencjalnie mniej „tarć” prawnych przy przekazywaniu e-dowodów do państw sygnatariuszy.
  • Ryzyka praw człowieka i R&D – Tech Accord ostrzega, że nieprecyzyjne definicje mogą ułatwić nadmierny nadzór i kryminalizować testy penetracyjne/bezpieczeństwa prowadzone w dobrej wierze, jeśli lokalne prawo implementujące będzie restrykcyjne. Potrzebne będą wyraźne wyjątki i bezpieczne przystanie dla badaczy (np. coordinated vulnerability disclosure).

Dla organów ścigania i CERT/CSIRT:

  • Szybszy dostęp do danych transgranicznych i łatwiejsze wspólne operacje w sprawach ransomware czy oszustw finansowych.

Rekomendacje operacyjne / co zrobić teraz

  1. Mapa jurysdykcyjna & readiness: zidentyfikuj, które kraje kluczowe dla Twojej działalności podpisały konwencję i śledź proces ratyfikacji (próg 40). Zaktualizuj playbooki SOC/LERT o tryby współpracy transgranicznej.
  2. Retencja i łańcuch dowodowy: ustandaryzuj politykę data preservation (czas, zakres, integralność), aby spełnić oczekiwania nowych kanałów pomocy prawnej.
  3. Legal & privacy by design: oceniaj wnioski o dane pod kątem zgodności z lokalnym prawem, RODO oraz klauzulami praw człowieka przewidzianymi przez konwencję; dokumentuj podstawy prawne i proporcjonalność.
  4. Program CVD/bug bounty: wprowadź/wyraźnie opisz zasady coordinated vulnerability disclosure i zakres „dozwolonych testów” (safe harbor) – to ogranicza ryzyko penalizacji etycznych badań w krajach o ostrzejszej implementacji. (Obawy branży: Cybersecurity Tech Accord).
  5. Ćwiczenia purple team: przetestuj scenariusze żądań danych z państw trzecich (różne formaty, SLA, szyfrowanie end-to-end), uwzględniając eskalacje do DPO/Legal.

Różnice / porównania z innymi przypadkami

Konwencja ONZ ma ambicję globalnego zasięgu i wspólnych, minimalnych standardów. W porównaniu z dotychczasową mozaiką porozumień i instrumentów regionalnych, stawia mocny akcent na ułatwienie dostępu do e-dowodów i mechanizmy 24/7. Jednocześnie zakres kategorii przestępstw i możliwe ingerencje w prywatność są szersze niż w wielu dotychczasowych reżimach – stąd krytyka NGO i sektora technologicznego, by implementacje krajowe nie prowadziły do nadużyć.

Podsumowanie / kluczowe wnioski

  • To się dzieje teraz: 25 października 2025 r. w Hanoi ruszył proces podpisywania; 65 podpisów na starcie podnosi szansę na szybkie przekroczenie progu 40 ratyfikacji.
  • Dla biznesu: przygotuj się na więcej i szybsze żądania o dane z zagranicy oraz audyty łańcucha dowodowego.
  • Dla bezpieczeństwa i prywatności: zadbaj o jasne wyjątki dla badań i procesy oceny proporcjonalności – inaczej istnieje ryzyko „efektu mrożącego” dla społeczności security.

Źródła / bibliografia

  • Reuters: „UN cybercrime treaty to be signed in Hanoi to tackle global offences” (25 października 2025). (Reuters)
  • UNODC (press): „UN Convention against Cybercrime opens for signature in Hanoi, Viet Nam” (25 października 2025). (UNODC)
  • UNODC (status): „United Nations Convention against Cybercrime — status & entry into force”. (UNODC)
  • Rada UE: „Fighting cybercrime: EU to sign UN Convention on cybercrime” (13 października 2025). (Consilium)
  • Cybersecurity Tech Accord: „Calls for changes to new UN treaty…” (29 lipca 2024) – stanowisko branży. (Cybersecurity Tech Accord)

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)

Smishing Triad powiązana z 194 tys. złośliwych domen. Globalna operacja smishingowa uderza także w Europę

Wprowadzenie do problemu / definicja luki

Chińskojęzyczna grupa przestępcza znana jako Smishing Triad prowadzi trwającą kampanię phishingu SMS (smishing), w której zidentyfikowano ponad 194 000 złośliwych domen zarejestrowanych od 1 stycznia 2024 r. Celem jest wyłudzanie danych płatniczych i tożsamości poprzez fałszywe powiadomienia o opłatach drogowych, niedoręczonych paczkach i usługach rządowych. Infrastruktura rejestracyjna i DNS jest powiązana m.in. z rejestratorem w Hongkongu, natomiast hosting w dużej mierze działa na popularnych chmurach w USA.

W skrócie

  • Skala: 194 345 FQDN w 136 933 domenach bazowych; dzienny churn tysięcy nowych domen.
  • Infrastruktura: DNS po stronie chińskich dostawców (np. AliDNS), hosting i IP głównie w USA (np. AS13335/Cloudflare).
  • Wejścia socjotechniczne: SMS-y o mandatach za bramki/autostrady, niedoręczonych przesyłkach, a coraz częściej – logowanie do kont maklerskich.
  • Zyski grupy: szacunkowo >1 mld USD w ciągu 3 lat – wg śledztwa prasowego.
  • Zasięg: kampania globalna; podszywanie się pod banki, giełdy krypto, poczty państwowe i usługi w krajach UE (m.in. Polska, Litwa).

Kontekst / historia / powiązania

O Smishing Triad informowano już w 2023–2025 r. jako o ekosystemie PhaaS (Phishing-as-a-Service), który sprzedaje kity phishingowe i usługi na Telegramie, umożliwiając wielu podwykonawcom realizację kampanii na skalę przemysłową. Nowsze analizy pokazują rozszerzenie celów poza pocztę i opłaty drogowe na finanse i maklerkę.

Analiza techniczna / szczegóły kampanii

  • Domeny i wzorce: popularne prefiksy typu com-, rosnący udział gov- w ostatnich miesiącach; krótkie, mylące łańcuchy z myślnikami mają udawać znane TLD/brand (np. imitacje serwisów rządowych). 71,3% domen żyje <7 dni, a <6% przetrwa 3 miesiące. Taki churn utrudnia blokowanie.
  • Rejestracja/DNS/Hosting: ~68% domen zarejestrowanych w Dominet (HK) Limited; serwery głównie w USA (m.in. Cloudflare), natomiast zarządzanie DNS często przez AliDNS i Cloudflare. ~43,5 tys. unikalnych adresów IP.
  • Najczęściej podszywane marki/kategorie: USPS (~28 tys. FQDN) oraz toll services (~90 tys. FQDN). Kampanie dotyczą też banków, krypto, e-commerce, policji i spółek państwowych w wielu krajach (w tym w Polsce i na Litwie).
  • Łańcuch dostaw PhaaS: deweloperzy kitów, brokerzy danych (sprzedaż numerów), sprzedawcy domen, dostawcy hostingu, spamerzy SMS/RCS/IM, skanery „liveness” numerów, skanery blocklist – każdy element można „zamówić”.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych i środków: wyłudzenia kart, danych osobowych, kodów OTP; dodawanie kart do portfeli mobilnych i szybkie wypłaty.
  • Ataki na konta maklerskie: po przejęciu kont sprawcy stosują „ramp & dump” (szybkie przeniesienie i pompowanie walorów niskiej płynności, a następnie realizacja zysków i cash-out).
  • Ryzyko dla organizacji: podszywanie się pod brandy (brand abuse), utrata zaufania klientów, koszty chargebacków i wsparcia.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/CSIRT i zespołów bezpieczeństwa

  1. Blokady DNS/URL: wdrażajcie feedy oparte na pDNS + wzorcach domenowych (prefiksy com-, gov- i hyfenizacja), z automatycznym wygaszaniem/aktualizacją z powodu krótkiego TTL życia domen.
  2. Polityki SMS: EDR/Mobile Threat Defense z detekcją linków w SMS/RCS/IM; regexy na słowa kluczowe dot. opłat drogowych/paczek i landingi z imitacjami CAPTCHy/ClickFix.
  3. Ochrona kont finansowych: wymuście FIDO2/U2F (klucze sprzętowe) dla dostępu do usług finansowych i paneli klienta – minimalizuje skuteczność smishingu i kradzieży OTP.
  4. Monitoring brand abuse: ciągły typosquatting + doppelganger hunt z fokusami na TLD .com/.gov-imitacje oraz nagły przyrost rejestracji prefixów.
  5. Współpraca z dostawcami: szybka eskalacja do Cloudflare/hosterów i rejestratorów (Dominet HK itd.) w celu zdejmowania serwisów phishingowych; automatyzacja zgłoszeń.

Dla banków/domów maklerskich i fintechów

  • MFA odporne na phishing (FIDO2), risk-based auth, „step-up” przy dodawaniu kart do portfeli mobilnych i większych przelewach; geofencing dla provisioningów walletów.
  • Detekcja anomalii giełdowych związanych z „ramp & dump” z kont detalicznych (niskopłynne tickery, krótkie okna).

Dla użytkowników końcowych

  • Nie klikaj w linki z SMS-ów o dopłatach, mandatach, paczkach; wpisuj adres ręcznie lub używaj oficjalnej aplikacji.
  • Włącz klucze bezpieczeństwa do logowania (gdzie to możliwe) i unikaj podawania kodów 2FA na stronach z linków z SMS.

Różnice / porównania z innymi przypadkami

W odróżnieniu od typowych kampanii smishingowych opartych na pojedynczych kitach i stałych domenach, Smishing Triad to zdecentralizowany ekosystem PhaaS z intensywną rotacją domen (churn), podziałem ról i globalnym zasięgiem. Warto porównać to z wcześniejszymi falami podszywania się wyłącznie pod przewoźników – dziś ciężar przesuwa się na finanse i maklerkę, co zwiększa bezpośrednie straty finansowe.

Podsumowanie / kluczowe wnioski

  • Mamy do czynienia z operacją przemysłową, a nie pojedynczą kampanią.
  • Automatyzacja detekcji na poziomie DNS/URL, krótki cykl TTP-based takedown oraz MFA odporne na phishing są krytyczne.
  • Organizacje w UE (w tym w Polsce) również znajdują się w wektorze podszywania – należy nasilić monitoring brand abuse i edukację klientów.

Źródła / bibliografia

  1. Palo Alto Networks Unit 42 – „The Smishing Deluge: China-Based Campaign Flooding Global Text Messages” (23 października 2025). (Unit 42)
  2. The Hacker News – „Smishing Triad Linked to 194,000 Malicious Domains…” (24 października 2025). (The Hacker News)
  3. Fortra – „Fortra Tracks Fivefold Increase in Brokerage Attacks YoY” (21 października 2025). (fortra.com)
  4. The Wall Street Journal – „Chinese Criminals Made More Than $1 Billion From Those Scam Texts” (14 października 2025). (The Wall Street Journal)
  5. Silent Push – „Threat Report: Smishing Triad” (26 czerwca 2025). (Silent Push)

Fałszywe „wnioski pośmiertne” w LastPass: kampania CryptoChameleon wyłudza hasła główne i celuje także w passkeys

Wprowadzenie do problemu / definicja luki

LastPass ostrzega przed trwającą od połowy października kampanią socjotechniczną podszywającą się pod mechanizm „dziedziczenia” (legacy/emergency access). Ofiary dostają e-maile sugerujące, że członek rodziny wnioskował o dostęp do sejfu po rzekłej śmierci właściciela, a w treści znajduje się „link do anulowania wniosku”. Kliknięcie prowadzi na fałszywą stronę „lastpassrecovery[.]com”, gdzie napastnicy wyłudzają hasło główne; w części przypadków atak jest wzmacniany telefonem od „pracownika LastPass” (tzw. hybrid phishing/call-back). Źródła i artefakty przypisują kampanię do grupy CryptoChameleon (UNC5356), wcześniej znanej z wyłudzeń na użytkownikach giełd krypto oraz z klonów stron logowania Okta/Gmail/iCloud/Outlook.

W skrócie

  • TTPs: e-mail z tematem “Legacy Request Opened (URGENT IF YOU ARE NOT DECEASED)” → call-to-action „Cancel request” → phishing na lastpassrecovery[.]com → kradzież hasła głównego; dodatkowo fałszywe telefony kierujące ofiarę na stronę phishingową; domeny pod passkeys (np. mypasskey[.]info, passkeysetup[.]com).
  • Atrybucja: infrastruktura i domeny powiązane z CryptoChameleon/UNC5356 (powiązania z kampaniami krypto-phishing).
  • Skala/zasięg: kampania aktywna od połowy października 2025 r.; część infrastruktury wygaszona, ale pojawiają się kolejne klony.
  • Ryzyko: kompromitacja sejfu haseł i/lub kradzież środków krypto, przejęcia kont, eskalacja na środowiska firmowe (SSO, poczta, CI/CD). Kontekst historyczny podnosi wagę ataku.

Kontekst / historia / powiązania

W 2022 r. LastPass ujawnił kradzież zaszyfrowanych kopii sejfów oraz danych niezaszyfrowanych (m.in. URL-e), co w kolejnych miesiącach korelowało z seriami kradzieży krypto u wybranych ofiar. W 2025 r. amerykańskie organy ścigania w dokumentach sądowych łączyły część dużych kradzieży (ok. 150 mln USD) z kompromitacjami związanymi z LastPass z 2022 r.

Dodatkowo 15 października 2025 r. raportowano inną kampanię phishingową celującą w użytkowników LastPass i Bitwarden, która wmawiała „włamanie” i skłaniała do instalacji „bezpieczniejszej wersji desktopowej” — w praktyce prowadziła do przejęcia stacji roboczej. To pokazuje ciągłe zainteresowanie ekosystemem managerów haseł przez cyberprzestępców.

Analiza techniczna / szczegóły luki

Wektor socjotechniczny:

  • Narracja „pośmiertna”: e-mail informuje o uruchomieniu procedury dziedziczenia (upload „aktu zgonu”) i zawiera fikcyjny numer agenta/case ID oraz priorytet sprawy — elementy, które podnoszą wiarygodność i presję czasu.
  • Phishing URL: przycisk „Cancel request” kieruje do lastpassrecovery[.]com (wskaźniki z przypisaniem do CryptoChameleon; hostowanie m.in. w NICENIC). Lista IOCs obejmuje także dziesiątki domen podszywających się pod Coinbase/Binance/Gemini/Gmail.
  • Call-back (voice social engineering): napastnicy dzwonią jako „LastPass Support” i nakłaniają do wpisania hasła głównego na stronie phishingowej.
  • Celowanie w passkeys: obecność wielu wariantów domen typu mypasskey[.]info i passkeysetup[.]com wskazuje na rozszerzenie ataku na FIDO2/WebAuthn (kradzież/eskalacja tokenów i sekwencji rejestracji).

Mechanizm „dziedziczenia” w LastPass (legalny): właściciel sejfu może zdefiniować kontakt awaryjny; po żądaniu dostępu biegnie okres karencji, po którym dostęp jest nadawany automatycznie, jeśli właściciel nie zareaguje. Atak nawiązuje do tej logiki, by zmuszać ofiarę do „anulowania” i wejścia w lewą stronę.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy indywidualni: ujawnienie hasła głównego = pełne przejęcie sejfu, pivot na mail/SSO/krypto; przy przechowywaniu seedów do portfeli – natychmiastowa kradzież środków. Kontekst z 2022–2025 r. pokazuje, że to nie są ataki hipotetyczne.
  • Firmy: ryzyko kompromitacji kont uprzywilejowanych, łańcuchowe przejęcia usług (MFA reset, IdP, repozytoria), BEC i naruszenia danych.
  • Zespół helpdesku: podatność na „voice phishing” i eskalacje na wewnętrzne procesy wsparcia (np. błędna weryfikacja tożsamości).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (natychmiast):

  1. Nigdy nie wpisuj hasła głównego po kliknięciu w link z e-maila/telefonu. Wchodź wyłącznie przez oficjalną aplikację lub ręcznie wpisany lastpass.com.
  2. Sprawdź w skrzynce temat: Legacy Request Opened (URGENT IF YOU ARE NOT DECEASED). Jeśli go masz — prześlij jako załącznik na abuse@lastpass.com.
  3. Włącz MFA dla LastPass i wszystkich krytycznych kont; rozważ zmianę hasła głównego i rotację haseł do kont wysokiej wartości (banki, krypto, e-mail).
  4. Jeśli używasz passkeys – upewnij się, że nie rejestrowałeś ich poprzez żaden link z e-maila; odrzuć nieoczekiwane prośby o rejestrację/uwierzytelnienie.

Dla SecOps/IT (w organizacji):

  1. Blokuj/monitoruj IOCs z bieżącej kampanii (domena lastpassrecovery[.]com, warianty mypasskey[.]info, podszycia pod giełdy i Gmail) w DNS/web proxy/EDR. Wdróż detekcje „Legacy Request” w treściach maili.
  2. Playbook SOAR: runbook na hybrydowy phishing + call-back (weryfikacja telefoniczna tylko poprzez oddzwonienie na oficjalne numery; żaden pracownik LastPass nie poprosi o hasło główne).
  3. Awareness: mikro-kampania dla pracowników (60-sek. wideo/komunikat) nt. „fałszywego dziedziczenia” i zasad bezpiecznej rejestracji passkeys.
  4. Zarządzanie tajemnicami: rozdziel sejfy prywatne/służbowe, segmentuj tajemnice; wymuś MFA hardware (FIDO2) tam, gdzie możliwe; rozważ detekcje anomalii w menedżerach haseł (próby odzyskiwania, masa-eksport haseł).
  5. Incident response: jeżeli podejrzewasz wpisanie hasła na phishingu – wymuś natychmiastową rotację i sprawdź eksport historii sejfu, logi logowań i ewentualne exfiltration events.

Różnice / porównania z innymi przypadkami

  • Październik 2025 (ten case): nacisk na dziedziczenie + call-back i targetowanie passkeys (nowość względem klasycznego phishingu na hasło główne).
  • 15 października 2025: osobna kampania „fałszywych alertów o włamaniu” wymuszająca instalację „bezpieczniejszej aplikacji” (wektor malware/PC hijack zamiast credential harvesting).
  • Kontekst 2022–2025: długofalowe skutki wycieku sejfów (brute-force offline na słabych hasłach, kradzieże krypto) – obecna kampania wykorzystuje te narracje i dane do skuteczniejszej socjotechniki.

Podsumowanie / kluczowe wnioski

  • To nie jest bug w LastPass, lecz wyrafinowana socjotechnika wykorzystująca realny proces „emergency access”.
  • Kampania CryptoChameleon łączy phishing mailowy, voice phishing i nowe cele (passkeys), co zwiększa skuteczność.
  • Organizacje powinny natychmiast wprowadzić bloki IOC, szkolenia „micro-awareness” i runbooki na call-back phishing; użytkownicy — MFA wszędzie, zerowa tolerancja na linki z e-maili i zgłaszanie podejrzanych wiadomości na abuse@lastpass.com.

Źródła / bibliografia

  • BleepingComputer: „Fake LastPass death claims used to breach password vaults”, 24.10.2025. (BleepingComputer)
  • LastPass (oficjalny blog): „Possible CryptoChameleon Social Engineering Campaign…”, 23.10.2025. (The LastPass Blog)
  • BleepingComputer: „Fake LastPass, Bitwarden breach alerts lead to PC hijacks”, 15.10.2025. (BleepingComputer)
  • KrebsOnSecurity: „Feds Link $150M Cyberheist to 2022 LastPass Hacks”, 07.03.2025. (Krebs on Security)
  • LastPass (komunikat): „Notice of Recent Security Incident”, 22.12.2022. (The LastPass Blog)

Masowe ataki na WordPress: przestępcy wykorzystują stare luki w GutenKit i Hunk Companion

Wprowadzenie do problemu / definicja luki

Od 8–9 października 2025 r. obserwowana jest kampania masowych ataków na strony WordPress, której celem są stare, ale wciąż powszechnie używane wersje wtyczek GutenKit oraz Hunk Companion. Według danych cytowanych przez BleepingComputer, dostawca zabezpieczeń Wordfence zablokował 8,7 mln prób w ciągu dwóch dni. Atakujący łączą podatności pozwalające bez uwierzytelnienia instalować dowolne wtyczki lub wgrywać pliki podszyte pod wtyczki, co eskaluje do zdalnego wykonania kodu (RCE).

W skrócie

  • Na celowniku: GutenKit (≤ 2.1.0 — CVE-2024-9234) i Hunk Companion (≤ 1.8.4 — CVE-2024-9707; ≤ 1.8.5 — CVE-2024-11972). Łatki: GutenKit 2.1.1 (X 2024), Hunk Companion 1.9.0 (XII 2024).
  • Wektor: nieautoryzowane endpointy REST umożliwiające instalację/aktywację wtyczek lub wgrywanie „fałszywych” paczek.
  • Łańcuch ataku: po uzyskaniu dostępu napastnicy doinstalowują złośliwą paczkę „up” albo podatną wtyczkę WP Query Console (brak poprawek, RCE), aby utrzymać trwałą kontrolę.
  • Ślady (IoC): żądania do /wp-json/gutenkit/v1/install-active-plugin, /wp-json/hc/v1/themehunk-import; katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Kontekst / historia / powiązania

Luki w Hunk Companion były już nagłaśniane pod koniec 2024 r. — CVE-2024-11972 jest poprawką/bypassem wcześniejszej CVE-2024-9707; obie ocenione jako CVSS 9.8 (krit.). W praktyce błędy umożliwiają atakującemu instalowanie i aktywowanie dowolnych wtyczek z repozytorium WordPress (także tych wycofanych), co stanowi wygodny „most” do RCE. Równolegle CVE-2024-9234 w GutenKit pozwala uploadować pliki podszyte pod wtyczki i aktywować je bez uprawnień.

Analiza techniczna / szczegóły luki

GutenKit (CVE-2024-9234). Brak właściwej autoryzacji/capability check w funkcji obsługującej install-active-plugin (REST) umożliwia nieautoryzowaną instalację/aktywację wtyczek lub wgranie arbitralnego pliku udającego wtyczkę (do 2.1.0 włącznie).

Hunk Companion (CVE-2024-9707, CVE-2024-11972). Błędy w endpointach themehunk-import (REST) pozwalają na nieautoryzowane POST-y skutkujące instalacją/aktywacją wtyczek. CVE-2024-11972 domyka wcześniejszą łatę i również oceniona jest na CVSS 9.8; wersja naprawcza to 1.9.0.

Eskalacja do RCE. Po pierwszym kroku atakujący:

  • instalują paczkę „up” (ZIP hostowany m.in. na zewnętrznych repozytoriach), zawierającą zaciemnione skrypty do uploadu, pobierania, usuwania plików i zmiany uprawnień; jeden z komponentów maskuje się jako element All in One SEO i automatycznie loguje napastnika jako admina,
  • albo doinstalowują podatną wtyczkę WP Query Console ≤ 1.0 (CVE-2024-50498, brak poprawek) i uzyskują RCE bez uwierzytelnienia.

IoC i TTP. W logach ruchu widoczne są żądania do:
/wp-json/gutenkit/v1/install-active-plugin oraz /wp-json/hc/v1/themehunk-import (sygnatura exploitów). W systemie plików sprawdź katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Praktyczne konsekwencje / ryzyko

  • Przejęcie strony i trwała persystencja (backdoory, automatyczny login na admina).
  • Eksfiltracja danych (pliki, konfiguracje, dane klientów), modyfikacje treści, wstrzykiwanie SEO-spam/malvertising.
  • Pivot na serwer — RCE pozwala wykorzystywać host do dalszych ataków (phishing, botnet, cryptomining).
  • Ryzyka prawne i reputacyjne (RODO, utrata pozycji SEO).
    Źródła branżowe raportują o łączeniu kilku luk w jeden łańcuch, co zwiększa automatyzację i skalę kampanii.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i audyt wersji

  • Natychmiast zaktualizuj:
    • GutenKit → ≥ 2.1.1,
    • Hunk Companion → ≥ 1.9.0.
  • Jeśli wtyczki są zbędne — usuń je całkowicie (dezaktywacja to za mało).

2) Detekcja nadużyć (logi i pliki)

  • Przeskanuj logi HTTP pod kątem:
    • "/wp-json/gutenkit/v1/install-active-plugin"
    • "/wp-json/hc/v1/themehunk-import"
  • Przeszukaj system plików:
    • katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Przykładowe polecenia (Linux):

# Szukaj podejrzanych żądań w access.log (Nginx/Apache)
grep -E 'wp-json/(gutenkit|hc)/v1/(install-active-plugin|themehunk-import)' /var/log/*/access.log*

# Wykryj "podejrzane" katalogi w instalacji WP
cd /var/www/html
find . -maxdepth 3 -type d -regex ".*/\(up\|background-image-cropper\|ultra-seo-processor-wp\|oke\|wp-query-console\)"

3) Ograniczenia i WAF

  • Tymczasowo blokuj/limituj dostęp do ww. endpointów REST (np. reguła WAF/ModSecurity) do czasu aktualizacji.
  • Stosuj Rate Limiting i blokowanie IP/ASN powiązanych z falą skanów (dane z bieżących raportów bezpieczeństwa).

4) Hardening WordPress

  • Włącz auto-update dla wtyczek i rdzenia.
  • Ogranicz liczbę adminów, wymuś MFA i klucze aplikacji dla integracji.
  • Utrzymuj kopie zapasowe offline i testuj odtwarzanie.

5) Incydent response (jeśli są ślady kompromitacji)

  1. Odizoluj witrynę (maintenance/firewall).
  2. Zrzut i analiza artefaktów: nowe konta admin, cron, wp-content/uploads, mu-plugins, wp-config.php.
  3. Usuń backdoory, zaktualizuj do bezpiecznych wersji, zresetuj hasła i klucze salts.
  4. Rozważ przywrócenie z kopii sprzed incydentu i pełny przegląd wtyczek (usuń porzucone).

Różnice / porównania z innymi przypadkami

  • Klasyczne RCE w wtyczce (np. WP Query Console) zwykle wymaga pojedynczej luki; tutaj napastnicy najpierw wymuszają instalację podatnej wtyczki przez inny błąd (REST), co zwiększa skuteczność automatycznych kampanii.
  • Specyfika WordPress.org: możliwość sięgnięcia po stare, wycofane paczki w repozytorium, co ułatwia „dowiezienie” RCE po uzyskaniu dostępu do endpointu instalacji.

Podsumowanie / kluczowe wnioski

  • Trwają zautomatyzowane, masowe ataki na WordPress z użyciem starych błędów w GutenKit i Hunk Companion, z potwierdzonymi milionami prób w krótkim czasie. Priorytetem jest aktualizacja lub deinstalacja podatnych wtyczek, przegląd logów pod kątem specyficznych endpointów REST oraz poszukiwanie charakterystycznych katalogów/pliki IoC. Dla zespołów SecOps to sygnał do tworzenia reguł WAF/IDS oraz blokad na poziomie infrastruktury.

Źródła / bibliografia

  1. BleepingComputer — „Hackers launch mass attacks exploiting outdated WordPress plugins”, 24 października 2025. (BleepingComputer)
  2. NVD — CVE-2024-9234 (GutenKit): opis błędu i wektor ataku. (NVD)
  3. NVD — CVE-2024-11972 (Hunk Companion): brak autoryzacji endpointów, wersja naprawcza. (NVD)
  4. WPScan — WP Query Console ≤ 1.0 — Unauthenticated RCE (CVE-2024-50498) — brak poprawek. (WPScan)
  5. SecurityWeek — łączenie luk Hunk Companion + WP Query Console do przejęcia stron (grudzień 2024). (SecurityWeek)

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)