Hintergrund
In diesen Tagen hat das Sicherheitssystem MistEye eine Spionagemalware entdeckt, die auf macOS läuft. Das Team von Mist Security startete daraufhin umgehend die Analyse.
Aus der Liste der gestohlenen Daten geht hervor, dass das Muster eher wie eine ziellose Datenernte wirkt: macOS Keychain, Safari-Cookies, Apple Notes, die lokalen Daten von Telegram Desktop sowie Datenbanken von mehr als einem Dutzend digitalen Wallets wurden allesamt in den Zielbereich aufgenommen.
Wie in dem vorherigen Artikel (Antrag auf Phishing im Google Sites Forum und Analyse einer macOS-Spionagemalware) beantworten wir die Frage: „Was hat die Malware gestohlen?“ Doch dass Dateien kopiert wurden, bedeutet nicht, dass der Account bereits verloren ist; dass die Wallet-Datenbank entwendet wurde, heißt noch lange nicht, dass die Seed-Phrase bereits offengelegt wurde. Daher geht dieser Beitrag noch einen Schritt weiter und fragt:
Nachdem diese Dateien gestohlen wurden—können sie wirklich in Konten- und Asset-Kontrollrechte umgewandelt werden?
Wir haben die Rekonstruktion in einer isolierten Umgebung anhand der Pfade nachgestellt, die im Sample hinterlassen wurden. Zuerst haben wir die aus dem Sample kopierten Telegram-Desktop-Sitzungsdateien auf einem Mac mit kompatibler Version wiederhergestellt und dann den Client gestartet。
Kein Login-Bildschirm erschien。
Keine Eingabe der Telefonnummer erforderlich, kein Versand von Verifizierungscodes, und keine Aufforderung zur Eingabe des Telegram-Zweitverifizierungs-Passworts. Der Client stellt den Kontostatus direkt wieder her und beginnt dann, den Chat-Verlauf zu synchronisieren。
Dieser Schritt lässt die Angriffskette zum ersten Mal von „statischen Dateien“ zu einem beobachtbaren Ergebnis werden: Der Angreifer trägt nicht einfach eine normale Konfiguration weg, sondern einen bereits verifizierten lokalen Zugangsausweis。
Anschließend haben wir noch einen weiteren Pfad verifiziert: Die Wallet-Datenbank und die Kandidatenpasswörter können in einer Offline-Umgebung zusammenkommen. Das Sample löscht außerdem den ursprünglich installierten Wallet-Client des Nutzers und ersetzt ihn durch eine Remote-Webview-Hülle mit offiziell wirkendem Namen und Icon。
Diese scheinbar verstreuten Funktionen fügen sich am Ende zu einer vollständigen Übernahme-Kette zusammen：
1. Passwörter, Entsperrmaterial und vorhandene Login-Sitzungen sammeln；
2. Die bereits autorisierten lokalen Telegram-Desktop-Sitzungen mitnehmen；
3. Wallet-Datenbank und Browser-Wallet-Erweiterungsstatus kopieren；
4. In der eigenen Umgebung des Angreifers offline entschlüsseln versuchen；
5. Gleichzeitig die offizielle Wallet löschen und durch eine Remote-WebView-App ersetzen, um den Nutzer zur aktiven Einreichung der Seed Phrase zu verleiten。
Dieser Artikel basiert auf dem statischen Analysebericht des Haupt-Samples, dem statischen Analysebericht der drei Wallet-Ersetzungs-Pakete, der logischen Gleichwertigkeit, die der Analyst anhand der Deassemblierung rekonstruiert hat, sowie zusätzlichen Hilfsdaten (LevelDB) zur Offline-Forensik-Verifikation。
Schritt 1: Passwörter und Entsperrmaterial sammeln
Telegram-Sitzungen können direkt wiederhergestellt werden, nicht weil der Angreifer das Telegram-Passwort geknackt hat. Die Wallet-Datenbank kann versucht werden zu entschlüsseln, nicht weil die Wallet-Software nicht verschlüsselt.
Zuerst muss der Angreifer so viele Passwörter, Entsperrmaterialien und noch gültige Login-Zustände wie möglich sammeln. Keychain, Browserdatenbanken, Apple Notes und der verkleidete Passwortdialog sind alles Bausteine für diesen Schritt。
Phishing-Passwort-Popup：
Das Sample öffnet ein Passwortdialogfenster, das sich als Google-API-Connector-Update tarnt：
Setze passwen auf Anzeige-Dialog „GAPI_Update erfordert Administratorzugriff, um den Google-API-Connector zu aktualisieren. Geben Sie Ihr Passwort ein, um fortzufahren.“ als Standardantwort „“ mit Vorsichtssymbol. Buttons: {„Continue“}. Standard-Button „Continue“. Abbruch nach 150 mit Titel „Password Request“ mit ausgeblendeter Antwort
vom passwen zurückgegebener Text
Es endet nicht damit, dass der Inhalt im Eingabefeld einfach gesammelt wird. Das Sample verwendet anschließend den dscl-Befehl von macOS, um zu prüfen, ob dieses Passwort wirklich die lokale Authentifizierung bestehen kann：
dscl . authonly '<aktueller Benutzername>' '<Kandidatenpasswort>'
Das heißt, das Sample versucht zu bestätigen, dass der Nutzer ein Login-Passwort für das lokale Gerät eingegeben hat und nicht einfach eine beliebige Zeichenkette. Nachdem die Prüfung erfolgreich ist, kann dieses Passwort für nachgelagerte Schritte wie Rechteerweiterung und App-Löschung weiterverwendet werden。
Browser- und Keychain-Zugriffsnachweise sammeln：
Gleichzeitig versucht das Sample, den Chrome Safe Storage Key aus der Keychain auszulesen：
security find-generic-password -ga "Chrome"2>&1 >/dev/null | sed -n 's/^password: "(.*)"/\1/p'
Das Ergebnis wird in die temporäre Datei masterpass-chrome geschrieben. Chrome Safe Storage kann man sich als einen Entschlüsselungsschlüssel vorstellen, den der Browser im macOS Keychain speichert. Damit kann der Angreifer die verschlüsselten Login-Daten und Cookies von Chrome zusammen mitnehmen und sie in seiner eigenen Umgebung weiter analysieren。
Der Browser-Sammelbereich der Samples umfasst Chromium-basierte Browser wie Chrome, Brave, Edge, Vivaldi, Opera usw. Zu den Ziel-Dateien gehören Login Data, Cookies, Web Data, formhistory.sqlite usw. Für Browser wie Firefox wird auf logins.json, key4.db und Cookie-Daten geachtet。
Das Sample lokalisiert und sammelt außerdem:
Keychains/login.keychain-db
Group Containers/group.com.apple.notes/NoteStore.sqlite
Ob in Notes tatsächlich Passwörter, Wallet-Seed-Phrases, Telegram-Passcode oder Wiederherstellungscodes gespeichert sind, hängt von den eigenen Aufzeichnungen des Nutzers ab. Auf Code-Ebene ist jedoch bereits die Fähigkeit vorhanden, auf Konto- und Inhaltsdaten zuzugreifen。
Daher erhält der Angreifer in dieser Phase nicht ein einzelnes Passwort, sondern eine Reihe von Materialien, die sich gegenseitig ergänzen können：
Direkte Passworteingabe: das macOS-Login-Passwort aus dem verkleideten Dialog abrufen；
Entsperrmaterial: Keychain, Chrome Safe Storage und die verschlüsselten Datenbanken des Browsers；
Äquivalente Credentials: Cookies, Inhalte aus Notes sowie nachfolgende Sitzungs- und Wallet-Daten。
Diese Materialien allein mögen nicht ausreichen, um ein Konto oder eine Wallet zu übernehmen, aber sie bereiten die Schlüssel für die spätere „Sitzungsverschiebung“ und „Offline-Entschlüsselung“ vor。
Schritt 2: Telegram-Sitzung mitnehmen
tdata-Sitzungsverzeichnis lokalisieren：
Das Sample richtet sich nicht an die Telegram-Webversion oder mobile App, sondern an den Telegram Desktop-Desktop-Client. Es sucht nach：
~/Library/Application Support/Telegram Desktop/tdata/
Hier kann man sich tdata hier ganz einfach so vorstellen: Telegram Desktop speichert eine Reihe von Sitzungsdaten lokal auf dem Gerät, um den Login-Status beizubehalten。
Das Sample kopiert die Dateien, die mit Schlüsseln, Konfiguration und Sitzungsstatus zu tun haben, einschließlich：
key_datas: hängt mit lokalen tdata-Schlüsseln oder Konfigurationen zusammen；
s: hängt mit dem lokalen Sitzungsstatus zusammen；
/maps: ein Teil der Zuordnung von Sitzungsdaten。
Basierend auf der logischen Gleichwertigkeit kopiert das Sample zuerst key_datas, durchläuft anschließend die Verzeichnisse, sucht nach gepaarten Sitzungsdateien und schreibt die relevanten Daten in das temporäre Verzeichnis：
Das ist nicht „eine Handvoll Telegram-Dateinamen suchen“, sondern eine klare Kette von Sitzungsdatei-Kopien. Nach Abschluss der Kopie komprimiert der Hauptprozess das temporäre Verzeichnis und lädt es hoch。
Sitzung wiederherstellen, Anmeldung umgehen：
Um die tatsächlichen Risiken nach der Exfiltration dieser Dateien zu verifizieren, haben wir in einer isolierten Umgebung eine version-kompatible Telegram Desktop-Installation (macOS 12.7 / Telegram Desktop 4.16) vorbereitet und die vom Sample gestohlenen Schlüsseldateien an den entsprechenden Stellen wiederhergestellt。
Für den Test wurden Testkonten verwendet, die keine echten Assets zugeordnet haben. Das Konto hatte Telegram 2FA (Zwei-Faktor-Authentifizierung) aktiviert, aber Telegram Desktop Passcode nicht aktiviert。
Nachdem die Dateien wiederhergestellt und der Client gestartet wurde, erschien der Login-Prozess nicht：
Keine Eingabe der Telefonnummer erforderlich；
Keine SMS-Verifizierung erforderlich；
Keine zweite Telegram-Verifizierungs-Passwortabfrage erforderlich。
Der Client stellte direkt den Login-Status des ursprünglichen Kontos wieder her und begann anschließend, den Chat-Verlauf zu synchronisieren。
Das bedeutet, dass der Angreifer nicht eine neue Kontoautorisierung benötigt, sondern eine lokale Sitzung, die weiterhin gültig ist。
Es wird nicht das Login-Passwort gestohlen, sondern ein bereits überprüfter „Zugangsausweis“。
Sitzungen wiederverwenden vs. 2FA knacken：
Hier muss man „2FA umgehen“ und „bestehende Sitzungen wiederverwenden“ unterscheiden。
Die Telegram-Zweitverifizierung schützt hauptsächlich neue Konto-Autorisierungsprozesse. Wenn der Angreifer direkt autorisierte lokale Sitzungsmaterialien wiederherstellt, führt der Client den vollständigen Authentifizierungsprozess für Telefonnummer, Verifizierungscode und Zweitverifizierungs-Passwort nicht erneut aus。
Daher lautet es genauer: Der Angreifer hat die bereits autorisierte lokale Sitzung wiederverwendet, sodass 2FA nicht erneut ausgelöst wurde. Das bedeutet nicht, dass das Telegram-2FA-Passwort geknackt wurde, sondern dass der gesamte Wiederverwendungsprozess nie in den Schritt gelangte, in dem dieses Passwort hätte verifiziert werden müssen。
Der Nutzer kann Auffälligkeiten möglicherweise nicht sofort bemerken：
In den Bedingungen dieses Tests weist die kopierte Sitzung auf dem Geräte-Listenbildschirm nicht stabil als eine klare, eigenständige neue Geräteautorisierungsaufzeichnung auf. Das bedeutet: Selbst wenn der Nutzer aktiv die bereits angemeldeten Geräte überprüft, erkennt er möglicherweise nicht sofort, dass die lokalen Sitzungsdaten kopiert wurden。
Wenn das Originalgerät und das Reproduktionsgerät längere Zeit parallel genutzt werden, kann der Server dazu führen, dass eine der beiden Sitzungen ungültig wird und eine erneute Anmeldung verlangt. In kürzeren, intermittierenden Zugrifftests werden Sitzungen jedoch nicht sofort zwangsweise beendet。
Die anomale Erkennung auf Serverseite kann die Lebensdauer einiger entwendeter Sitzungen verkürzen, aber sie kann den Schutz der lokalen tdata-Daten nicht ersetzen。
Wenn Telegram Desktop Passcode aktiviert hat, kann es nach der Wiederherstellung der Sitzung dennoch sein, dass der Angreifer aufgefordert wird, dieses Passwort einzugeben. Das kann zwar eine zusätzliche Schutzschicht schaffen, aber dieses Trojaner-Sample sammelt gleichzeitig Keychain-, Apple-Notes- und Browserdaten. Wenn der Nutzer Telegram-Passcode an diesen Stellen protokolliert hat oder ein Passwort in mehreren Apps wiederverwendet hat, kann diese Schutzschicht dennoch durchbrochen werden。
tdata kann weiter in eine API-Sitzung umgewandelt werden：
Neben den oben genannten Methoden haben wir zudem festgestellt: Wenn man die Telegram-tdata erhält, kann man zusammen mit opentele, Telethon, einem bereits autorisierten AuthKey und den Parametern der offiziellen Client-API den lokalen Login-Status in eine programmierbare Telegram-API-Sitzung umwandeln. Diese dient dazu, Dialoge, Verlaufsnachrichten und Nachrichten zu lesen und zu senden. Tests zeigen, dass das Skript nur über kurze, unterbrochene Verbindungen arbeiten kann und nicht dauerhaft online bleiben muss, wodurch das Risiko verringert wird, dass sofortige, anomale Logout-Vorgänge ausgelöst werden. Da die bestehende Autorisierung wiederverwendet wird, entstehen keine neuen Geräte-Logins; in der Geräte-Liste taucht auch kein klarer, eigenständiger neuer Eintrag für ein neues Gerät auf. Nutzer erkennen Auffälligkeiten daher nur schwer, selbst wenn sie die angemeldeten Geräte prüfen。
Auch bei Telegram für macOS besteht ein Risiko durch Sitzungswiederverwendung：
Die obige Analyse richtet sich auf Telegram Desktop (plattformübergreifender Desktop-Client auf Basis von Qt). Aber Telegram bietet unter macOS noch einen weiteren Kanal: den nativen Client Telegram für macOS (Swift-native Version, unabhängig über App Store oder die offizielle Website heruntergeladen). Tests dieser Version zeigen, dass auch ihre lokalen Sitzungsdateien kopiert und auf einem anderen Mac direkt wiederhergestellt werden können: kein Erfordernis von Telefonnummer, Verifizierungscode oder Zweitverifizierungs-Passwort, um ins Konto zu gelangen; in der Liste der Login-Geräte gibt es außerdem keinen neuen Eintrag, der die Reproduktionsmaschine repräsentiert。
Darüber hinaus gibt es bei Telegram für macOS im Hinblick auf die Reaktion auf Sicherheitsmechanismen einen bemerkenswerten Unterschied im Vergleich zu Telegram Desktop: Wenn der Server ein anomales Login-Verhalten erkennt, wird Telegram für macOS nicht wie die Desktop-Version zwangsweise ausgeloggt und löscht auch nicht die lokalen Daten. In unseren Tests blieb der von den Sicherheitsmechanismen markierte Client zwar so, dass er keine neuen Nachrichten senden oder empfangen konnte, aber die Oberfläche blieb weiterhin geöffnet. Dadurch kann der Angreifer weiterhin lokale, bereits vorhandene Verlaufs-Chats ansehen und durchblättern. Das heißt: Selbst wenn der Server bereits reagiert hat, können zuvor zwischengespeicherte Verlaufsnachrichten weiterhin vollständig zurückverfolgt werden, ohne dass ein erzwungenes Blockieren erfolgt。
Das bedeutet, dass in diesem Angriffsszenario der native macOS-Client für den Nutzer nicht über den normalen Faktor „neues Login-Gerät hinzufügen“ wahrnehmbar ist, und selbst nach einer serverseitigen Erkennung bleibt der Chat-Verlauf nach außen offen: Der Angreifer hat zwar die Fähigkeit zum Senden und Empfangen in Echtzeit verloren, aber die bereits zwischengespeicherten Verlaufsinhalte können weiterhin vollständig gelesen werden。
Ab hier ist der Telegram-Teil klar: Egal ob Telegram Desktop oder Telegram für macOS—der Angreifer muss sich nicht erneut bei dem Konto anmelden. Er braucht nur eine bereits autorisierte lokale Sitzung vom Mac des Opfers in seine eigene Umgebung zu übertragen。
Schritt 3: Wallet-Daten stehlen
Telegram-Sitzungen können direkt wiederverwendet werden, während Wallet-Datenbanken üblicherweise noch eine zusätzliche Verschlüsselungsschicht haben. Das Vorgehen im Sample besteht darin, zunächst so viele Wallet-Daten wie möglich zu kopieren, um Raum für die anschließende Analyse zu lassen。
Abdeckung von 16 Wallets vollständig：
Das Sample durchsucht 16 Arten lokaler Wallets oder Wallet-Management-Clients. Darunter sind Software-Wallets, Core-ähnliche Full-Node-Clients sowie die dazugehörigen Management-Programme für Hardware-Wallets：
Software-Wallets：Electrum, Coinomi, Exodus, Atomic, Wasabi, Monero, Electrum LTC, Electron Cash, Guarda, Sparrow；
Core-ähnliche Clients：Bitcoin Core, Litecoin Core, Dash Core, Dogecoin Core；
Passende Clients für Hardware-Wallets：Ledger Live, Trezor Suite。
Die Datenverzeichnisse, Datenbankformate und Verschlüsselungsmethoden verschiedener Wallets sind nicht identisch. Die grundlegende Strategie der Samples ist jedoch gleich: Verzeichnis finden, Wallet-Datenbank und Konfigurationsdateien kopieren, paketieren und exfiltrieren, anschließend in der eigenen Angreifer-Umgebung weiter analysieren。
Beim Kopieren überspringt das Sample Cache-, Code Cache-, Crashpad-, journals-, media-, calls- sowie andere Cache- und Noise-Verzeichnisse und behält bevorzugt Daten zu Konto- und Wallet-Status bei。
Das hat eine leicht zu unterschätzende Folge: Selbst wenn die Wallet-Daten verschlüsselt sind, kann der Angreifer, sobald die vollständige Datenbank exfiltriert wurde, das Entschlüsseln wiederholt außerhalb des Geräts des Opfers versuchen. Wenn das Opfer die Wallet schließt, die Netzwerkverbindung trennt oder sogar den Trojaner löscht, kann es die bereits kopierten Daten nicht zurückholen。
Browser-Erweiterungen sammeln：
Neben Desktop-Wallets scannt das Sample außerdem Konfigurationsverzeichnisse von mehr als zehn Chromium-Kernbrowsern wie Chrome, Brave, Edge, Vivaldi, Opera usw.。
Es richtet sich auf das Default- oder Profile-Verzeichnis jedes Browsers und sammelt Cookies, Login-Daten, Daten von Webformularen sowie lokale Erweiterungsspeicher und IndexedDB-Daten. Im Sample sind 223 Erweiterungs-IDs mit Wallet-Bezug eingebettet, um den lokalen Speicher verschlüsselter Wallet-Erweiterungen zu filtern und zu kopieren。
Diese Daten entsprechen nicht dem Klartext-Seed Phrase, aber sie können Wallet Vaults, Konto-Konfigurationen, Autorisierungsstatus und Browser-Login-Material enthalten. Damit lassen sich Offline-Analysen, Zustandsmigrationen und nachgelagerte gezielte Phishing-Angriffe durchführen。
Bis hierhin hat der Angreifer bereits zwei Arten entscheidender Materialien in der Hand: auf der einen Seite eine verschlüsselte Wallet-Datenbank, auf der anderen Seite Kandidaten-Passwörter, die aus dem System, dem Browser und Notes gesammelt wurden. Der nächste Schritt ist zu prüfen, ob diese beiden Materialarten zusammengefügt werden können。
Schritt 4: Wallet offline entschlüsseln
Zum Beispiel Atomic Wallet：
Wir wählen Atomic Wallet für die lokale Reproduktion. Das Sample kopiert das LevelDB-Lokalspeicher-Verzeichnis von Atomic Wallet. LevelDB ist ein gängiges lokales Datenbankformat, in dem die Wallet den Kontostatus und sensible Daten speichert。
Die Daten in diesem Verzeichnis werden mit AES-256-CBC verschlüsselt; zum Entschlüsseln wird das Wallet-Passwort benötigt。
Daher bedeutet das alleinige Vorliegen einer LevelDB-Datei nicht, dass der Angreifer bereits die Klartext-Seed Phrase hat. Das Wallet-Passwort ist weiterhin die „Tür“ zwischen der Datenbank und sensiblen Daten。
Doch diese „Tür“ muss man in der gesamten Angriffskette beobachten, um sie zu verstehen。
Passwörter aus mehreren Quellen nacheinander ausprobieren：
In der isolierten Testumgebung (Atomic Wallet 2.70) haben wir die vom Sample kopierten LevelDB-Daten wiederhergestellt und die Kandidatenpasswörter, die der Trojaner von Stellen wie Keychain, Browser-Passwortmanager, Apple Notes usw. gesammelt hatte, Schritt für Schritt zur Entschlüsselung verwendet。
Schließlich konnte ein Kandidatenpasswort erfolgreich Daten entschlüsseln, die Materialien zur Steuerung von Assets enthielten。
Dieser Schritt deckt die gefährlichste Stelle im Sample auf: Der Angreifer muss nicht unbedingt nach einer kryptografischen Schwachstelle der Wallet-Software selbst suchen, und auch nicht in Echtzeit Passwörter auf dem Computer des Opfers ausprobieren。
Es sind nur zwei Dinge, die es mitnehmen muss: eine verschlüsselte Wallet-Datenbank und eine Reihe von Passwörtern, die möglicherweise dem Nutzer gehören. Die Datenbank ist wie ein weggetragener Tresor, und die Kandidatenpasswörter sind eine Liste von Ersatzschlüsseln mit komplexer Herkunft. Der Angreifer kann sie in einer offline Umgebung ohne Zeiteinschränkungen nacheinander verifizieren。
Nach der Exfiltration des Private Keys nicht mehr widerrufbar：
Sobald Private Keys, Seed Phrase oder gleichwertige Asset-Steuerungsmaterialien wiederhergestellt sind, beschränkt sich das Risiko nicht mehr nur auf einen einzelnen Wallet-Client. Der Angreifer kann dieselbe Adresse in einer anderen kompatiblen Wallet wiederherstellen und die entsprechende Kontrolle über die Assets erhalten。
In diesem Fall können das Ändern des Passworts der App, eine Neuinstallation des Clients oder sogar das Löschen lokaler Wallet-Dateien nicht verhindern, dass die bereits exfiltrierten Private Keys oder Seed Phrases ungültig werden。
Bis hier ist der Offline-Entschlüsselungspfad für Wallet-Daten klar. Aber das Sample macht damit nicht Schluss—für einige besonders wertvolle Ziele setzt es noch einen weiteren parallelen Angriffspfad ein。
Schritt 5: Wallet-App ersetzen
Bösartige ZIP-Ersetzungs-App herunterladen：
Im Haupt-Sample fanden wir eine Reihe von Aktionen, die sich deutlich von klassischem Diebstahl einzelner Dateien unterscheiden: Der Trojaner lädt drei ZIP-Pakete von einem Remote-Server in das /tmp-Verzeichnis herunter und löscht gleichzeitig das ursprünglich installierte Ledger Live, Ledger Wallet und Trezor Suite des Nutzers。
Die swap_app()-Funktion im Haupt-Sample führt einen vollständigen Ersetzungsablauf aus: Mit curl wird ein komprimiertes Paket heruntergeladen, mit pkill wird der laufende Wallet-Prozess beendet, anschließend wird mit rm -rf die ursprüngliche App gelöscht; falls nötig erfolgt eine Privilegeskalation per sudo. Abschließend wird mit ditto das komprimierte Paket nach /Applications entpackt。
Ersetzungs-Paket ist nur ein Web-Loader：
Anhand von Dateinamen und Symbolen scheinen diese ZIP-Pakete jeweils zu drei offiziellen Wallet-Clients zu gehören. Reverse-Engineering zeigt jedoch, dass sie keine echte Wallet-Funktionalität implementieren。
Der Kernablauf der drei Ersetzungsprogramme ist sehr ähnlich: Sie lesen eine versteckte Konfiguration, entschlüsseln eine Remote-Route per XOR, setzen daraus eine vollständige URL zusammen, erstellen eine WKWebView mit aktivem JavaScript und laden dann die Remote-Seite, die der Angreifer kontrolliert。
WKWebView kann man sich als eine Webfenster-Komponente vorstellen, die in die Desktop-App eingebettet ist. Sie kann die Benutzeroberfläche der App überlagern, ohne wie ein Browser-Tab aufzutauchen。
Statische Analyse bestätigt: Das Ersetzungs-Paket aktiviert JavaScript und speichert persistente Daten, findet jedoch keine echte Geschäftsimplementierung von Ledger oder Trezor. Keine USB/HID-Kommunikation, keine Enumeration von Hardwaregeräten, keine BIP39/BIP32-Key-Derivation und keine Transaktionskonstruktion oder lokale Signatur。
Mit anderen Worten: Es handelt sich nicht um einen modifizierten Wallet-Client, sondern um einen Web-Loader, der mit Wallet-Namen und -Icons verkleidet ist。
Die drei Remote-Adressen, die am Ende von den Ersetzungs-Apps geladen werden, sind：
Ledger Live und Ledger Wallet zeigen auf dieselbe /ledger-Route, Trezor Suite lädt dagegen die /trezor-Route. Da es sich um Remote-Seiten handelt, bedeutet das: Der Angreifer muss keine lokalen Apps erneut veröffentlichen—er kann jederzeit den Seiteninhalt, die Interaktionsformulierungen und die Logik zur Datenübermittlung ändern。
Phishing-Seite hinter dem Desktop-Icon：
Wenn der Nutzer die ersetzten „Wallet“-Apps startet, kann die Remote-Seite so tun, als wäre es ein Wallet-Wiederherstellungs-, Verifizierungs- oder Initialisierungsprozess, und den Nutzer dazu anleiten, die Seed Phrase, PIN, Passphrase oder andere Wiederherstellungsunterlagen einzugeben。
Für normale Nutzer ist das weitaus schwerer zu erkennen als eine klassische Phishing-Webseite. Die Seite erscheint nicht in einem Browser-Tab, sondern in einer Desktop-Anwendung, die in /Applications installiert ist und einen vertrauten Namen sowie ein bekanntes Icon hat。
Der Nutzer könnte denken, das sei ein Verifizierungsprozess nach einem Wallet-Upgrade, oder er könnte glauben, dass er sein Konto gemäß offiziellen Anweisungen wiederherstellt。
Wenn der Nutzer in dieser Remote-Seite die Seed Phrase einreicht, erhält der Angreifer nicht mehr den zeitlich begrenzten Zugriff auf eine einzelne App, sondern das höchste Kontrollzertifikat für Wallet-Assets。
Offline-Entschlüsselung bedeutet: Man sucht in bereits vorhandenen Daten nach der Seed Phrase；Ersetzen der App bedeutet: Nutzer dazu verleiten, die Seed Phrase selbst einzugeben. Beide Wege laufen parallel und sind voneinander unabhängig。
Angriffsketten-Übersicht
Noch einmal zurück zur ursprünglichen Diebstahlliste betrachtet: Keychain, Cookie, Notes, Telegram und Wallet-Dateien scheinen voneinander unabhängige Ziele zu sein. Nach der Reproduktion wird die Beziehung zwischen ihnen klar：
Keychain, Browser und Notes liefern Passwörter, Passcode und weiteres Entsperrmaterial；
Safari-Cookies können weiterhin gültige Web-Login-Sitzungen bereitstellen；
Telegram tdata stellt autorisierte Kontositzungen bereit；
Wallet-Datenbank stellt verschlüsselte Daten bereit, die mitgenommen, kopiert und offline analysiert werden können；
Die ersetzten Ledger- und Trezor-Apps führen den Nutzer über einen anderen, unabhängigen Pfad zu einer Remote-Phishing-Seite。
Jedes Modul für sich betrachtet wirkt wie eine gängige Spionage-/Datendiebstahlhandlung. Wirklich gefährlich wird es dadurch, dass das Sample diese Materialien miteinander kombiniert。
Für Telegram umgeht der Angreifer nicht die Stärke eines Passworts, sondern die erneute Authentifizierung selbst. Für lokale Wallets nutzt der Angreifer die Tatsache, dass verschlüsselte Daten und Passwortmaterial gleichzeitig gestohlen werden. Für Ledger und Trezor versucht der Angreifer sogar nicht mehr, vorhandene Daten zu knacken; stattdessen definiert er durch den Austausch des Clients die „vertrauenswürdige Oberfläche“, die der Nutzer wahrnimmt, neu。
Was der Angreifer wirklich braucht, ist oft nicht ein einzelnes Passwort, sondern dass autorisierte Sitzungen, verschlüsselte Daten und Entsperrmaterial gleichzeitig in die Hände geraten。
Zusammenfassung
Dieser Trojaner stiehlt nicht nur ein paar isolierte Passwörter oder Dateien, sondern das gesamte lokale Vertrauensverhältnis, das der Nutzer nach und nach auf einem Mac aufgebaut hat: bereits eingeloggene Sitzungen, gespeicherte Passwörter, eine verschlüsselte Wallet und das Vertrauen des Nutzers in Desktop-Anwendungen selbst。
Wenn all diese Dinge das Gerät verlassen—vom Informationsleck über die Kontenübernahme bis hin zum Diebstahl digitaler Assets—fehlt in der Mitte nur noch eine einzige erfolgreiche Datenkombination。
Zwei-Pfade-Wallet-Angriff. Das Sample bereitet für die Wallet-Assets zwei sich gegenseitig absichernde Pfade vor: Der erste ist das Stehlen der Wallet-Datenbank und der Kandidaten-Passwörter für die Offline-Entschlüsselung；Der zweite ist der Austausch des Hardware-Wallet-Clients, das Laden einer Remote-Seite und das Verleiten des Nutzers zur aktiven Einreichung der Seed Phrase. Beide Pfade laufen parallel und decken jeweils „passives Stehlen“ und „aktives Anleiten“ ab。
Sitzungswiederverwendung statt Passwortknacken. Der Telegram-Angriff ist nicht auf Passwortknacken oder 2FA-Umgehung angewiesen. Der Angreifer kopiert direkt die bereits autorisierten lokalen Sitzungsdateien, stellt den Login-Status in einer neuen Umgebung wieder her und löst den gesamten Vorgang ohne erneute Authentifizierung aus。
Nutzung kombinierter Credentials aus mehreren Quellen. Das Sample setzt nicht auf Passwörter aus einer einzigen Quelle, sondern sammelt Kandidatenpasswörter über mehrere Kanäle wie Keychain, Browser-Passwortmanager, Apple Notes und einen verkleideten Dialog. So steigt die Chance, die Wallet-Datenbank offline zu entschlüsseln。
Empfehlung
Wenn festgestellt wird, dass der Host möglicherweise infiziert ist, sollten Sie alle bestehenden Telegram-Sitzungen auf einem vertrauenswürdigen Gerät sofort beenden, den vertrauenswürdigen Login-Status neu herstellen und das Telegram-Zweitverifizierungs-Passwort sowie den Passcode ändern. Das Ändern nur des 2FA-Passworts macht die bereits kopierten lokalen Sitzungen nicht zwangsläufig sofort ungültig。
Sobald die Wallet-Datenbank oder das Private-Key-Material möglicherweise offengelegt wurden, müssen Sie neue Seed Phrases auf einem sauberen Gerät oder in einer vertrauenswürdigen Hardware-Wallet generieren, das Vermögen so schnell wie möglich auf eine neue Adresse migrieren und die alten Seed Phrases nicht mehr verwenden. Das Ändern des Passworts der Wallet-App allein macht bereits geleakte Private Keys oder Seed Phrases nicht ungültig。
Keychain rotieren, Apple Notes und alle Passwörter, die im Browser gespeichert oder wiederverwendet wurden; besonderes Augenmerk auf E-Mail, Exchanges, Cloud-Speicher, Passwortmanager und Social-Accounts, und die bestehenden Login-Sitzungen in diesen Diensten abmelden。
Für Ledger- oder Trezor-Clients, die möglicherweise gelöscht und ersetzt wurden: Entfernen Sie zuerst verdächtige Apps, prüfen Sie die Codesignatur und die Installationsquelle, klären Sie relevante Persistenz-Einträge (z. B. LaunchDaemon) und holen Sie das Installationspaket dann über offizielle vertrauenswürdige Kanäle neu. Wenn in der ersetzten App eine Seed Phrase eingegeben wurde, behandeln Sie dies sofort so, als sei die Seed Phrase geleakt worden。
Für selten genutzte Telegram-Clients (z. B. Desktop oder native macOS-Clients, die nur auf bestimmten Geräten installiert, aber lange nicht geöffnet werden) sollten Sie den Login-Status regelmäßig überprüfen oder Sitzungen, die nicht mehr benötigt werden, aktiv beenden. Da solche Clients selten genutzt werden, fällt es Nutzern oft nicht rechtzeitig auf, wenn der Login-Status gestohlen und in einer Angreifer-Umgebung wiederhergestellt wurde. Sicherheitsprüfungen auf Serverseite stützen sich typischerweise auf Veränderungen im Verhaltensmuster aktiver Sitzungen. Bei Clients, die lange im „stillschweigenden“ Zustand sind, sind anomale Logins schwerer automatisch zu erkennen. Sobald sie kompromittiert wurden, kann der Angreifer möglicherweise lange einen stillen Kontrollzugriff auf das Konto behalten und neue Nachrichten fortlaufend lesen, ohne dass irgendwelche Alarme ausgelöst werden。
Im täglichen Gebrauch sollten Sie für Telegram einen Passcode aktivieren und ein hochstarkes Passwort setzen, das sich von anderen Passwörtern unterscheidet, um die lokalen Sitzungen zusätzlich abzusichern. Vermeiden Sie die Verwendung schwacher Passwörter。
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
Bösartige Datei
Dateiname: ledger.zip SHA256: 41d77fef030b8515efb068defed5e15c14fbebd16259253f1f79febd6e12ebcb
Dateiname: ledgerwallet.zip SHA256: 36f4ae11560ed34f32c927468a09a5370a5fbdcae41660f6e8d9a49330c8d059
Dateiname: trezor.zip SHA256: 60f33e7b8c6b84839e28c710c8c5a99a718c0b88135653561be8d45f976b794f
Über MistEye
MistEye ist eine von SlowMist selbst entwickelte Web3 Threat Intelligence- und dynamische Sicherheitsüberwachungsplattform. Über APIs bietet sie Open-Source-Paket-Ökosystem-Erkennungsfunktionen für bösartige Aktivitäten sowie Warnungen zu Supply-Chain-Risiken。
Alle bösartigen Pakete und die zugehörigen IOC dieser Aktion sind in die MistEye Threat Detection Engine integriert. Entwickler können über die API die Abhängigkeiten eines Projekts automatisiert prüfen, schnell feststellen, ob es bekannte bösartige Pakete trifft, und Empfehlungen zur Handhabung erhalten。
📖 API-Dokumentation：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan Ein leichtgewichtiges CLI-Tool, das in einer einzigen Befehlszeile Projektabhängigkeiten und bekannte bösartige Pakete in global installierten Paketen scannt. Unterstützt das npm-/PyPI-/Cargo-/Go-/RubyGems-Ökosystem
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skills Paket von AI-Code-Assistent-Sicherheitsfähigkeiten: triggert MistEye-Sicherheitsprüfungen automatisch vor dem Installieren von Abhängigkeiten und vor dem Aufrufen von URLs
Dieser Artikel wurde vom SlowMist-Threat-Intelligence-Team in Kombination mit dem MistEye-Threat-Intelligence-System sowie dem von SlowMist Agent AI gesteuerten Analyseprozess erstellt. Bei Fragen wenden Sie sich bitte jederzeit an das Team—Feedback und Rückmeldungen sind willkommen。