Nadużycie wtyczek Obsidian jako wektor początkowego dostępu. Kampania z PHANTOMPULSE RAT uderza w sektor finansowy i krypto

securitybeztabu.pl 9 godzin temu

Wprowadzenie do problemu / definicja

Zaufane aplikacje produktywności coraz częściej stają się elementem łańcucha ataku. Najnowszy przykład dotyczy Obsidiana, popularnego narzędzia do tworzenia i synchronizacji notatek, którego mechanizmy konfiguracji oraz ekosystem wtyczek społecznościowych zostały wykorzystane do uruchomienia złośliwego kodu. W opisywanej kampanii celem byli użytkownicy z sektora finansowego i kryptowalutowego, a końcowym ładunkiem na systemach Windows był wcześniej nieudokumentowany trojan zdalnego dostępu PHANTOMPULSE.

W skrócie

Atak rozpoczął się od ukierunkowanej socjotechniki prowadzonej przez komunikację na LinkedIn i Telegramie. Ofiary otrzymywały dostęp do współdzielonego repozytorium notatek w Obsidianie, które miało wyglądać jak roboczy dashboard związany z finansami i płynnością rynku kryptowalut.

Kluczowym elementem było nakłonienie użytkownika do manualnego włączenia synchronizacji zainstalowanych wtyczek społecznościowych. Po spełnieniu tego warunku Obsidian uruchamiał polecenia poprzez legalną wtyczkę Shell Commands, a dodatkowa wtyczka Hider ukrywała część interfejsu. Na Windows prowadziło to do wdrożenia łańcucha PHANTOMPULL → PHANTOMPULSE, natomiast na macOS do uruchomienia droppera AppleScript.

Kontekst / historia

Ten incydent nie opierał się na klasycznej luce typu RCE w samym Obsidianie. To istotne rozróżnienie, ponieważ atakujący nie złamali bezpieczeństwa aplikacji poprzez exploit, ale wykorzystali jej zamierzone funkcje w połączeniu z precyzyjnie przygotowaną manipulacją użytkownikiem. Taki model działania wpisuje się w rosnący trend nadużywania legalnych narzędzi i zaufanych procesów zamiast dostarczania oczywiście podejrzanych plików wykonywalnych.

Z perspektywy obrońcy kampania jest szczególnie interesująca, ponieważ granica bezpieczeństwa nie została przekroczona automatycznie. Wymagane było świadome działanie ofiary: otwarcie współdzielonego vaulta oraz aktywacja synchronizacji komponentów społecznościowych. To oznacza, iż skuteczność ataku zależała bardziej od wiarygodności pretekstu biznesowego niż od zaawansowanej eksploatacji technicznej.

Analiza techniczna

Mechanizm infekcji bazował na konfiguracji vaulta i plikach JSON przechowywanych w strukturze Obsidiana. Złośliwa logika nie musiała więc przyjmować formy typowego malware dostarczanego jako załącznik lub plik binarny na pierwszym etapie. Po stronie ofiary uruchomienie poleceń następowało w kontekście podpisanej i zaufanej aplikacji Electron, co utrudnia wykrywanie oparte wyłącznie na reputacji procesu nadrzędnego.

W scenariuszu Windows uruchamiany był skrypt PowerShell, którego zadaniem było dostarczenie pośredniego loadera nazwanego PHANTOMPULL. Ten komponent odszyfrowywał i ładował do pamięci adekwatny backdoor PHANTOMPULSE. Takie podejście ogranicza liczbę artefaktów zapisywanych na dysku i utrudnia detekcję sygnaturową.

PHANTOMPULSE zapewniał pełny zestaw funkcji typowych dla nowoczesnego RAT-a. Z dostępnych informacji wynika, iż malware potrafił pobierać polecenia z serwera C2, przesyłać dane telemetryczne systemu, wysyłać wyniki wykonanych komend, przesyłać pliki i zrzuty ekranu, a także rejestrować naciśnięcia klawiszy. Wspierane były również działania ofensywne takie jak iniekcja shellcode’u, DLL lub EXE do procesu ofiary, zapis i uruchomienie plików na dysku, deinstalacja mechanizmów trwałości oraz eskalacja uprawnień do poziomu SYSTEM z użyciem mechanizmu COM elevation moniker.

Szczególnie interesujący był sposób rozwiązywania adresu C2 na Windows. Zamiast stosować wyłącznie statyczną infrastrukturę, malware korzystał z łańcucha Ethereum do odczytu danych z najnowszej transakcji powiązanej z zakodowanym adresem portfela. Taki model utrudnia analizę i blokowanie, ponieważ część logiki sterowania zostaje przeniesiona do publicznej infrastruktury blockchain.

Na macOS zastosowano odmienny tor wykonania. Wtyczka Shell Commands uruchamiała zaciemniony dropper AppleScript, który iterował po zakodowanej liście domen i wykorzystywał Telegram jako mechanizm zapasowego rozwiązywania infrastruktury C2. Ostatecznie dropper pobierał i uruchamiał drugi etap przez osascript. Charakter końcowego ładunku dla macOS nie został jednoznacznie potwierdzony, ponieważ infrastruktura sterująca była już niedostępna w momencie analizy.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dotyczy organizacji, które dopuszczają szerokie użycie narzędzi produktywności bez kontroli konfiguracji, synchronizacji i instalowanych rozszerzeń. Atak pokazał, iż legalna funkcja synchronizacji może zostać przekształcona w kanał wykonania poleceń oraz w mechanizm utrzymywania złośliwej konfiguracji.

Dla sektorów finansowego, inwestycyjnego i kryptowalutowego zagrożenie jest ponadprzeciętne. Tego typu użytkownicy regularnie komunikują się z nowymi partnerami, funduszami, brokerami czy dostawcami płynności, więc scenariusz współdzielonego dashboardu lub repozytorium analitycznego jest dla nich wiarygodny. Po skutecznym wdrożeniu RAT-a napastnik może uzyskać dostęp do poufnych danych, kont, portfeli kryptowalutowych, materiałów due diligence, a także przechwycić dane uwierzytelniające i rozszerzyć kompromitację na kolejne systemy.

Ryzyko detekcyjne również jest istotne. jeżeli organizacja polega głównie na klasycznych silnikach AV i blokowaniu znanych hashy, może nie zauważyć aktywności osadzonej w konfiguracji aplikacji i uruchamianej przez legalne komponenty. To wymusza większy nacisk na telemetrykę zachowań, monitorowanie uruchomień PowerShell, osascript oraz nietypowych potomków procesów aplikacji desktopowych.

Rekomendacje

Organizacje powinny ograniczyć możliwość instalacji i synchronizacji wtyczek społecznościowych w aplikacjach, które nie są objęte formalnym procesem dopuszczenia. W praktyce oznacza to polityki allowlist, kontrolę konfiguracji użytkownika oraz monitorowanie zmian w katalogach konfiguracyjnych vaultów Obsidiana.

Z punktu widzenia SOC i zespołów blue team warto wdrożyć reguły wykrywające:

uruchomienie PowerShell lub interpreterów skryptowych przez Obsidiana,
uruchomienie osascript z kontekstu aplikacji notatkowej,
nagłe pojawienie się poleceń wykonywanych przez Shell Commands,
nietypowe modyfikacje plików JSON i katalogu .obsidian,
komunikację do rzadkich lub nowo zarejestrowanych domen po otwarciu współdzielonych vaultów.

Istotne jest także wzmacnianie odporności użytkowników na socjotechnikę. Należy uczulić zespoły, iż prośba o manualne włączenie synchronizacji wtyczek, makr, dodatków lub konfiguracji w zewnętrznym workspace powinna być traktowana jako sygnał ostrzegawczy. W środowiskach wysokiego ryzyka warto rozważyć uruchamianie takich aplikacji w odseparowanych profilach roboczych lub kontenerach.

Dodatkowo rekomendowane jest:

blokowanie lub ograniczanie interpretera PowerShell i AppleScript zgodnie z zasadą najmniejszych uprawnień,
monitorowanie eskalacji uprawnień przez mechanizmy COM,
segmentacja stacji roboczych użytkowników uprzywilejowanych i zespołów operujących aktywami kryptograficznymi,
przegląd narzędzi produktywności pod kątem funkcji umożliwiających lokalne wykonanie poleceń.

Podsumowanie

Opisana kampania pokazuje, iż nowoczesne ataki coraz częściej nie wymagają klasycznej podatności w aplikacji. Wystarczy połączenie zaufanego narzędzia, legalnej funkcjonalności oraz dobrze przygotowanej socjotechniki. Nadużycie ekosystemu wtyczek Obsidiana do dostarczenia PHANTOMPULSE RAT jest przykładem przesunięcia ciężaru ataku z exploitu na konfigurację i zachowanie użytkownika. Dla obrońców oznacza to konieczność monitorowania nie tylko luk i malware, ale również sposobu, w jaki aplikacje biznesowe mogą zostać użyte jako nośnik wykonania kodu, trwałości i komunikacji z infrastrukturą napastnika.