Fałszywy instalator OpenAI Codex nakłaniał użytkowników Maców do uruchomienia malware

Zwykłe wyszukiwanie narzędzia dla programistów mogło zakończyć się infekcją Maca. Badacze Cato CTRL z firmy Cato Networks opisali kampanię, w której reklamy sponsorowane w Google dla zapytań takich jak „codex macos download” kierowały użytkowników na przekonująco wyglądającą kopię strony pobierania OpenAI Codex. Witryna była dostępna za pośrednictwem Google Sites, ale nie oferowała prawdziwego instalatora. Zamiast tego nakłaniała odwiedzającego do samodzielnego uruchomienia złośliwego polecenia w Terminalu. 2910

Pułapka zaczynała się od reklamy w Google

Kampania była wymierzona w osoby, które już szukały sposobu na zainstalowanie Codex na macOS. Złośliwa reklama pojawiała się obok, a potencjalnie także nad legalnymi wynikami wyszukiwania i prowadziła do strony Google Sites stylizowanej na oficjalny portal pobierania OpenAI Codex. Fałszywy serwis prezentował opcje dla macOS i Linuksa, jednak badacze zaobserwowali aktywne dostarczanie ładunku wyłącznie użytkownikom macOS. 510

Wykorzystanie prawdziwej domeny Google Sites pomagało ukryć oszustwo. Adres sites.google.com mógł wyglądać mniej podejrzanie niż nowo zarejestrowana domena kojarzona z malware. Według relacji operatorzy korzystali również z wykradzionych kont Google Ads, co mogło nadawać reklamom pozory ciągłości i wiarygodności znanego reklamodawcy. 12

ClickFix przenosił najważniejszy krok na ofiarę

Fałszywy portal nie proponował pobrania typowego pliku DMG, który użytkownik musiałby później otworzyć. Zamiast tego instruował go, aby uruchomił Terminal i wkleił podane polecenie. To przykład techniki socjotechnicznej nazywanej ClickFix: napastnik przedstawia rzekomą czynność instalacyjną lub naprawczą, a ofiara sama wykonuje kluczowy etap uruchomienia ataku. 21213

Polecenie zaczynało się od wiarygodnie wyglądającego ciągu związanego z instalacją Codex przez npm. W rzeczywistości dekodowało adres URL zapisany w Base64, pobierało zdalny skrypt i przekazywało go do powłoki zsh systemu macOS. 3413

To podejście wykorzystuje przyzwyczajenia programistów do instalowania narzędzi z poziomu wiersza poleceń. Eliminuje też jeden z oczywistych sygnałów ostrzegawczych: użytkownik nie otrzymuje niespodziewanego pliku aplikacji, który mógłby najpierw sprawdzić. Decyzja o zaufaniu zostaje przedstawiona jako zwykłe skopiowanie komendy konfiguracyjnej z pozornie oficjalnej strony produktu. 212

Łańcuch infekcji prowadził do podejrzanego AMOS-a

Dostępne relacje opisują wieloetapowy proces dostarczania malware. Po uruchomieniu wklejonego polecenia kolejne skrypty pobierały końcowy plik wykonywalny Mach-O, zapisywały go jako /tmp/helper, usuwały jego atrybuty rozszerzone poleceniem xattr -c, nadawały mu uprawnienia do uruchomienia i otwierały plik. 3411

Usunięcie atrybutów rozszerzonych może pozbyć się związanych z kwarantanną metadanych macOS i ograniczyć liczbę ostrzeżeń wyświetlanych przy otwieraniu pobranego pliku. 411 Według opisów technicznych końcowy plik obsługiwał zarówno procesory Intel, jak i układy Apple Silicon. 1521

Cato wskazało na silne podobieństwa do publicznie opisywanej aktywności Atomic macOS Stealer, znanej jako AMOS. Inne relacje określały ładunek jako podejrzewanego infostealera AMOS, a nie prawdziwy komponent Codex. 29 Ten rodzaj malware jest kojarzony z kradzieżą danych przeglądarek, danych logowania oraz informacji z portfeli kryptowalutowych. 1

Zaufane elementy budowały wiarygodną ścieżkę do infekcji

Skuteczność kampanii nie opierała się na jednym wyjątkowo zaawansowanym exploicie. Napastnicy połączyli kilka znajomych użytkownikom sygnałów:

• Intencja wyszukiwania: reklama trafiała do osób aktywnie szukających instalacji Codex.
• Płatna pozycja: wynik sponsorowany pojawiał się w bardzo eksponowanym miejscu wyszukiwarki Google. 912
• Hosting Google: strona docelowa korzystała z legalnej domeny sites.google.com. 29
• Podszywanie się pod markę: portal naśladował branding OpenAI Codex. 1012
• Język programistów: polecenie przypominało typową instalację npm. 35
• Uruchomienie przez użytkownika: ClickFix sprawiał, że ofiara sama wykonywała komendę, zamiast otwierać nieoczekiwany instalator. 213

Fałszywy portal wykorzystywał także ramkę iframe do wyświetlania treści kontrolowanych przez napastników z osobnej, złośliwej domeny. Dzięki temu widoczna strona mogła zachować wiarygodność Google Sites, a operatorzy zyskiwali większą kontrolę nad samym procesem instalacji. 9

W dodatkowych relacjach pojawiają się twierdzenia o mechanizmach unikania wykrycia, takich jak odpowiedzi zależne od urządzenia i adresu URL czy podmienianie ładunku. Dostępne materiały nie potwierdzają jednak niezależnie wszystkich szczegółów ich implementacji. Należy więc traktować je ostrożnie, a nie jako potwierdzone cechy całej kampanii.

Co z tego wynika dla użytkowników Maców?

Najważniejsza zasada jest prosta: polecenie skopiowane ze strony pobierania nadal oznacza wykonanie kodu. Reklama w Google, znajomy branding ani adres hostowany przez Google nie dowodzą, że instrukcja jest prawdziwa.

Przy instalowaniu narzędzi dla programistów komendy wymagają takiej samej ostrożności jak pobierane pliki wykonywalne. Warto sprawdzać wydawcę i sposób instalacji w znanych, oficjalnych kanałach produktu, unikać wklejania nieprzejrzystych poleceń do Terminala oraz traktować komendy zawierające zakodowane adresy URL lub zdalne skrypty jako poważny sygnał ostrzegawczy.

Ta kampania pokazuje, że współczesne malware coraz częściej atakuje nie sam produkt, lecz drogę prowadzącą do jego instalacji. Reklama w wyszukiwarce budowała początkowe zaufanie, hosting Google je wzmacniał, branding OpenAI sprawiał, że strona wyglądała znajomo, a ClickFix zamieniał to zaufanie w uruchomienie malware przez samego użytkownika. 234