Claude.ai jako zaufany nośnik phishingu

TL;DR

Atakujący wykorzystali zaufanie do platform AI w nowy sposób: nie tylko podszywali się pod marki takie jak Claude, ChatGPT Codex, Perplexity, Cursor czy JetBrains, ale też przenieśli część kampanii na prawdziwą domenę claude.ai. Zamiast fałszywej strony na podejrzanej domenie użytkownik widział współdzielony czat Claude z instrukcją, która wyglądała jak pomoc techniczna albo instalacja narzędzia.

Według Trend Micro kampania zaczynała się od reklam w Google i fałszywych stron na GitLab Pages, a później nadużyła funkcji współdzielonych czatów Claude. Użytkownik trafiał na realny adres claude.ai/share/..., gdzie instruowano go, aby otworzył Terminal i wkleił komendę. Ta komenda pobierała kolejne skrypty i prowadziła do uruchomienia malware MacSync, które mogło kraść m.in. dane z przeglądarek, cookies, klucze SSH i pliki portfeli kryptowalutowych.

To jest ważny temat dla firm, bo zmienia prostą zasadę nie klikaj w podejrzane linki. W tym scenariuszu sam link może wyglądać wiarygodnie. Ryzyko kryje się w instrukcji po kliknięciu: skopiuj komendę, uruchom terminal, napraw błąd, dokończ instalację.

Dlaczego to zasługuje na osobny wpis

The Hacker News opisał ten przypadek w zbiorczym biuletynie ThreatsDay, ale sam wątek Claude ma własną wartość dla PHISHLY. To nie jest tylko kolejna kampania malware ani kolejny przykład podszywania się pod markę AI. Najważniejszy mechanizm polega na nadużyciu zaufanej funkcji legalnej platformy.

W klasycznym phishingu użytkownik uczy się patrzeć na domenę. Jeśli domena jest dziwna, literówka podejrzana, a certyfikat lub wygląd strony nie pasuje do marki, łatwiej przerwać proces. Tutaj część tego sygnału znika, bo użytkownik ląduje na domenie znanej usługi AI.

To nie oznacza, że Claude zostało włamane albo że sama platforma jest z natury niebezpieczna. Mechanizm jest bardziej subtelny: atakujący wykorzystali legalną funkcję udostępniania rozmów jako nośnik instrukcji socjotechnicznej. Podobny problem może dotyczyć każdej platformy, która pozwala publikować treści pod zaufaną domeną.

Dla użytkownika wniosek jest konkretny: zaufana domena nie wystarcza, jeśli strona prosi o wykonanie ryzykownej czynności poza przeglądarką.

Jak działał łańcuch ataku

Trend Micro opisał kampanię obserwowaną od 8 kwietnia do 14 czerwca 2026 roku. W pierwszych falach atakujący używali reklam Google i stron na GitLab Pages. Podszywali się pod narzędzia popularne wśród osób technicznych: Claude AI, ChatGPT Codex, Perplexity, Cursor IDE i JetBrains. To nie był przypadkowy zestaw nazw. To marki, których szukają developerzy, administratorzy, osoby pracujące z kodem i narzędziami AI.

Najpierw użytkownik wpisywał w wyszukiwarce frazę związaną z narzędziem AI. Reklama lub wynik prowadził do strony wyglądającej jak instrukcja pobrania albo konfiguracji. W kolejnych falach kampania przeszła na współdzielone czaty Claude. Atakujący tworzyli publiczne rozmowy na claude.ai, które wyglądały jak przewodnik techniczny lub pomoc Apple Support.

Następnie pojawiał się element ClickFix. Użytkownik miał otworzyć Terminal i wkleić polecenie. Samo polecenie było przedstawiane jako techniczny krok instalacji, naprawy błędu albo uruchomienia narzędzia. W rzeczywistości pobierało ono skrypt z infrastruktury atakujących, który prowadził do uruchomienia infostealera.

To jest szczególnie groźne dla osób technicznych, bo terminal, curl, skrypty instalacyjne i polecenia kopiowane z dokumentacji nie są dla nich niczym nietypowym. Atak działa, bo przypomina normalny workflow.

ClickFix: gdy użytkownik sam uruchamia atak

ClickFix jest jedną z najbardziej niebezpiecznych form socjotechniki, bo zmienia rolę użytkownika. Ofiara nie tylko klika link. Ofiara wykonuje instrukcję, która uruchamia złośliwy kod na jej własnym urządzeniu.

W prostszych wariantach ClickFix użytkownik widzi fałszywy błąd CAPTCHA, komunikat przeglądarki albo instrukcję naprawy problemu. Ma skopiować polecenie, wkleić je do PowerShell, Terminala albo okna uruchamiania systemu i nacisnąć Enter. To wygląda jak obejście problemu technicznego, ale w praktyce omija wiele warstw obrony.

W tym przypadku ClickFix został połączony z modą na narzędzia AI i zaufaniem do legalnych platform. Użytkownik nie pobiera losowego pliku z nieznanej domeny. Użytkownik czyta instrukcję na stronie, która wydaje się wiarygodna, i wykonuje komendę, bo sądzi, że tak wygląda instalacja lub konfiguracja.

Na PHISHLY podobny mechanizm pojawiał się już przy fałszywych spotkaniach Zoom i ClickFix. Różnica polega na tym, że tutaj atak mocniej wykorzystuje zaufanie do platform AI i do współdzielonych treści publikowanych pod ich domenami.

Zaufana domena nie oznacza zaufanej instrukcji

Najważniejsza lekcja z tej kampanii dotyczy zmiany sygnałów zaufania. Firmy i użytkownicy często koncentrują się na tym, czy adres strony jest znany. To nadal ma sens, ale nie wystarcza.

Legalna domena może hostować treści użytkowników, współdzielone dokumenty, formularze, komentarze, repozytoria, strony projektów, czaty albo materiały generowane przez osoby trzecie. Atakujący mogą nadużyć takiej funkcji, aby przenieść przynętę na domenę, która normalnie ma dobrą reputację.

To samo zjawisko widać w innych klastrach phishingu: GitHub Pages, Google Forms, SharePoint, Adobe, Netlify, Vercel, Cloudflare Pages czy różne narzędzia no-code. Sama platforma jest legalna, ale treść pod konkretnym linkiem może być złośliwa.

Dlatego edukacja użytkowników nie może kończyć się na sprawdź domenę. Trzeba dodać drugie pytanie: co ta strona każe mi zrobić?

Jeżeli strona prosi o uruchomienie komendy, instalację profilu, nadanie uprawnień OAuth, wpisanie kodu MFA, pobranie pliku, zmianę rachunku albo podanie danych karty, trzeba traktować to jako operację wysokiego ryzyka. Nawet jeśli adres wygląda dobrze.

Polski i firmowy kontekst

W polskich firmach podobny scenariusz może dotyczyć developerów, administratorów, analityków danych, zespołów marketingu, konsultantów, osób testujących AI i pracowników, którzy samodzielnie szukają narzędzi zwiększających produktywność.

Pracownik może szukać instalatora Claude Desktop, rozszerzenia do IDE, narzędzia do generowania kodu, aplikacji do transkrypcji, wtyczki do dokumentów albo poradnika dla macOS. Jeżeli trafi na sponsorowany wynik lub współdzieloną stronę na znanej platformie, może uznać instrukcję za wiarygodną.

W środowiskach developerskich dodatkowym problemem jest normalizacja komend instalacyjnych. Polecenia typu curl, bash, npm, pip, brew albo PowerShell pojawiają się w prawdziwej dokumentacji. Użytkownik techniczny może więc szybciej zaakceptować ryzykowną instrukcję niż osoba nietechniczna.

Dla firm korzystających z Microsoft 365, Google Workspace, GitHub, GitLab, Jira, Slack, Teams, narzędzi AI i środowisk chmurowych skutki mogą być poważne. Infostealer uruchomiony na urządzeniu developera może szukać cookies, tokenów, kluczy SSH, danych z przeglądarek, konfiguracji repozytoriów, dostępu do środowisk testowych i informacji zapisanych lokalnie.

To już nie jest tylko problem prywatnego laptopa. To może być wejście do procesu firmowego, repozytorium, chmury albo kont SaaS.

Co powinien zrobić użytkownik

Użytkownik nie powinien instalować narzędzi AI z reklam, przypadkowych wyników wyszukiwania ani współdzielonych stron, nawet jeśli są hostowane na znanej domenie. Bezpieczniejsza ścieżka to ręczne wejście na oficjalną stronę producenta, firmowy katalog aplikacji albo dokumentację zatwierdzoną przez IT.

Najważniejszy sygnał alarmowy to polecenie typu skopiuj i uruchom komendę. Jeżeli strona każe otworzyć Terminal, PowerShell, okno uruchamiania systemu albo wkleić polecenie, użytkownik powinien przerwać proces i zgłosić link do IT lub Security.

Dotyczy to szczególnie komend, których sensu użytkownik nie rozumie. Base64, długie ciągi znaków, pobieranie skryptów z internetu, przekierowania przez curl lub podobne narzędzia, automatyczne uruchamianie pobranego kodu i wyłączanie zabezpieczeń powinny być traktowane jako czerwone flagi.

Jeżeli instalacja narzędzia AI jest potrzebna do pracy, powinna mieć potwierdzoną ścieżkę: dokumentację wewnętrzną, zatwierdzony pakiet, MDM, firmowy sklep aplikacji albo oficjalnego menedżera pakietów.

Co powinny zrobić IT, Security i SOC

Zespoły bezpieczeństwa powinny traktować wspólne linki do platform AI jako potencjalny kanał dostarczania treści, a nie automatycznie zaufane źródło. Nie chodzi o blokowanie całego claude.ai czy chatgpt.com, tylko o rozumienie, że pod zaufaną domeną może znaleźć się treść użytkownika.

Dla SOC ważne są zachowania po wejściu na stronę. Jeśli po sesji w przeglądarce użytkownik uruchamia Terminal, PowerShell, osascript, curl, zsh, bash, mshta albo podobne narzędzia, to może być sygnał ClickFix. Szczególnie gdy polecenie pobiera skrypt z internetu, dekoduje dane, uruchamia kod w pamięci albo kontaktuje się z nową domeną.

W środowiskach developerskich warto ograniczyć samowolną instalację narzędzi i wtyczek AI. Pomaga lista zatwierdzonych narzędzi, wewnętrzna dokumentacja instalacji, monitorowanie nowych rozszerzeń IDE, kontrola uprawnień do repozytoriów i ochrona sekretów takich jak klucze SSH, tokeny API i dane chmurowe.

Ten scenariusz warto połączyć z istniejącymi procedurami dotyczącymi phishingu, OAuth i przejmowania sesji. Wpis o ConsentFix v3 i phishingu OAuth dobrze pokazuje podobną zmianę: użytkownik nie zawsze wpisuje hasło na fałszywej stronie. Czasem wykonuje prawdziwą akcję w złym kontekście.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik tylko wszedł na stronę, ale nie uruchomił komendy, powinien zgłosić link i zamknąć stronę. Zespół bezpieczeństwa może sprawdzić, czy podobny link trafił do innych osób, czy pojawił się w reklamach, komunikatorach lub dokumentacji wewnętrznej.

Jeżeli użytkownik skopiował i uruchomił komendę, urządzenie należy potraktować jako potencjalnie skompromitowane. Nie należy samodzielnie kasować historii, usuwać plików ani restartować procesu bez uzgodnienia z IT/Security, jeśli firma ma procedurę obsługi incydentów. Ważne są artefakty: polecenie, adresy URL, czas wykonania, procesy, logi i ruch sieciowy.

Jeżeli urządzenie było używane do pracy z kodem, chmurą, pocztą, repozytoriami, systemami SaaS albo portfelami kryptowalutowymi, trzeba założyć możliwość kradzieży sekretów. Do sprawdzenia są klucze SSH, tokeny API, cookies, sesje przeglądarkowe, menedżery haseł, profile przeglądarki, pliki konfiguracyjne i dostęp do repozytoriów.

Następnie trzeba unieważnić aktywne sesje, zrotować klucze i tokeny, sprawdzić logowania, zweryfikować zmiany w repozytoriach i ocenić, czy z urządzenia nie wysłano danych na zewnątrz. Jeżeli malware mogło wykraść dane osobowe lub służbowe, incydent powinien trafić do odpowiednich właścicieli procesu, nie tylko do zespołu technicznego.

Jak ćwiczyć ten scenariusz w awareness

Scenariusz z Claude shared chat i ClickFix jest bardzo dobry do ćwiczeń, bo nie opiera się na oczywistym błędzie. Użytkownik może zobaczyć znaną domenę, wiarygodny kontekst, techniczny opis i instrukcję, która przypomina prawdziwą dokumentację.

W kontrolowanym teście można sprawdzić kilka momentów decyzji. Czy użytkownik kliknie reklamę zamiast wejść na oficjalną stronę? Czy zauważy, że instrukcja każe uruchomić komendę? Czy zgłosi podejrzany shared chat? Czy osoba techniczna wykona polecenie, bo brzmi jak normalna instalacja?

W testach phishingowych dla firm taki scenariusz pozwala mierzyć coś więcej niż kliknięcie. Można sprawdzić, czy użytkownik rozpoznaje ryzykowną instrukcję po kliknięciu i czy organizacja potrafi zareagować, zanim komenda zostanie uruchomiona.

Najlepszy materiał szkoleniowy powinien pokazać nie tylko zrzut strony, ale też logikę ataku: reklama, zaufana domena, instrukcja, terminal, skrypt, malware, kradzież sekretów. Dopiero wtedy użytkownik rozumie, że problemem nie była sama marka Claude, tylko zaufanie do czynności wykonanej bez weryfikacji.

Zasada na koniec

W tym scenariuszu nie wystarczy pytać, czy domena wygląda prawdziwie. Trzeba zapytać, co strona próbuje wymusić.

Jeżeli zaufana platforma, reklama albo współdzielony czat każe uruchomić komendę, wkleić skrypt, nadać uprawnienia albo zainstalować narzędzie poza zatwierdzonym procesem, właściwą reakcją jest przerwanie działania i zgłoszenie. Zaufana domena nie może zastąpić zaufanej procedury.