#cyberpedia

Si parla di:

Toggle

Da febbraio 2026 un nuovo #trojan bancario per #Android circola con un obiettivo dichiarato: l’#Ucraina. Ma “trojan bancario” è ormai una definizione troppo stretta per Manic, il #malware descritto in un #report di ThreatFabric come “un ibrido tra malware bancario e #spyware”. Oltre a rubare PIN e credenziali finanziarie, Manic intercetta #SMS, seed phrase di wallet #crypto, cronologia chiamate e posizione #GPS — e, quando il telefono infetto è #offline, trova comunque il modo di far uscire i dati sfruttando altri dispositivi compromessi nelle vicinanze via Bluetooth e Wi-Fi Direct. È una capacità che ridefinisce cosa significhi davvero “isolare” un dispositivo compromesso.

Non una schermata di phishing, ma una tastiera che origliaLa maggior parte dei trojan bancari Android si affida a overlay che imitano l’interfaccia dell’app bersaglio per catturare le credenziali digitate dalla vittima. Manic fa qualcosa di più subdolo: grazie ai permessi di Accessibility Service, determina la posizione della tastiera digitale legittima dell’app e registra i singoli tocchi dell’utente senza alterare in alcun modo il funzionamento dell’app originale. Il risultato è che la vittima interagisce con la sua banca reale, sullo schermo reale, mentre in background il malware classifica ogni sequenza digitata — PIN di sblocco, seed phrase di wallet, codici OTP, password — semplicemente osservando dove e quando avvengono i tocchi.

A questa capacità si aggiungono sessioni di controllo remoto vere e proprie via WebRTC, con visualizzazione live dello schermo, mascherate dietro overlay neri o finte schermate di aggiornamento di sistema; la possibilità di sbloccare il dispositivo da remoto tramite la funzione autoEnterPin, una volta che il PIN è stato catturato; e comandi dedicati per disattivare Google Play Protect (disable_gp), così da ridurre le probabilità di essere rilevati anche dalle protezioni native di Android.

169 applicazioni monitorate, priorità all’UcrainaThreatFabric ha censito 169 identificatori di applicazioni nella lista bersagli di Manic: banche, exchange di criptovalute, app di pagamento P2P e “buy now pay later”, client email e browser. Il dato più significativo, però, è la composizione geografica dei target: il malware dà priorità esplicita a banche ucraine, servizi eID e piattaforme governative, oltre ad app di messaggistica sia commerciali sia a uso militare — una scelta che, nel contesto del conflitto in corso, suggerisce un interesse che va oltre la semplice frode finanziaria. La lista si estende poi a istituti finanziari in Russia, Polonia, Repubblica Ceca, Slovacchia, Austria, Germania, Francia, Spagna, Paesi Bassi, Estonia, Lituania e Regno Unito, con distribuzione tramite siti di phishing e dropper che si spacciano per utility di sistema o aggiornamenti di componenti Android/produttore (i nomi dei package individuati imitano deliberatamente Huawei, Honor, Lenovo, Motorola e persino Apple).

Lo sviluppo del malware appare tutt’altro che concluso. ThreatFabric ricostruisce una timeline chiara: la prima infrastruttura viene registrata a febbraio 2026, i servizi di produzione entrano in funzione tra marzo e aprile, la prima versione operativa di wrapper e implant compare a maggio, mentre a luglio arriva un aggiornamento che introduce protezioni anti-analisi rafforzate, caricamento del codice DEX direttamente in memoria (per complicare l’analisi statica) e un meccanismo di phishing per il “lock secret” del dispositivo.

Quando internet non basta: l’esfiltrazione mesh via BluetoothLa caratteristica più originale di Manic — e quella che lo distingue nettamente dal panorama dei trojan Android — è il meccanismo di esfiltrazione dati progettato per funzionare anche quando il dispositivo infetto non ha accesso diretto a internet. I dati rubati vengono cifrati con AES-GCM e messi in una coda locale; il malware cerca poi altri dispositivi infetti nelle vicinanze tramite Wi-Fi Direct, Bluetooth RFCOMM o BLE GATT, costruendo percorsi “store-and-forward” multi-hop — fino a 4 salti per impostazione predefinita — capaci di far arrivare i dati a internet passando di device in device, finché uno di essi non trova connettività diretta. Se nessuna rotta è disponibile nell’immediato, i dati restano semplicemente in coda per essere ritrasmessi al primo tentativo utile.

Come sintetizzano gli stessi ricercatori di ThreatFabric, “rimuovere l’accesso diretto a internet da un dispositivo infetto non impedisce necessariamente l’esfiltrazione dei dati”. È una considerazione che dovrebbe far riflettere chi progetta contromisure basate solo su segmentazione di rete o blocco della connettività cellulare/Wi-Fi: in scenari con più dispositivi compromessi nello stesso ambiente — un ufficio, un’abitazione, persino un evento pubblico — la rete mesh creata dal malware stesso diventa il canale di comunicazione, aggirando completamente i controlli perimetrali tradizionali pensati per un singolo endpoint.

Due righe per i difensoriPer i team di sicurezza mobile e per gli istituti finanziari nei paesi target, Manic impone di ripensare due assunzioni comuni. La prima è che il monitoraggio comportamentale lato server (fraud detection basata su pattern di digitazione o velocità di interazione) rimane efficace anche quando l’attaccante non altera l’interfaccia dell’app: qui serve piuttosto rilevare l’uso anomalo di servizi di Accessibility da parte di app di terze parti non correlate al contesto bancario. La seconda è che l’isolamento di rete di un dispositivo sospetto non è più una garanzia sufficiente, quando l’esfiltrazione può avvenire tramite protocolli short-range verso dispositivi terzi già compromessi.

Verificare quali app hanno richiesto e ottenuto permessi di Accessibility Service e Notification Listener, specie se provenienti da fonti fuori Google Play

Monitorare pattern anomali di connessioni Wi-Fi Direct/Bluetooth in ambienti aziendali e finanziari sensibili

Diffidare di dropper che si presentano come aggiornamenti di componenti di sistema legati a specifici produttori (Huawei, Honor, Lenovo, Motorola)

Mantenere attivo Google Play Protect e verificare periodicamente lo stato di attivazione, dato che Manic include comandi dedicati per disattivarlo

Per le banche: rafforzare l’autenticazione multi-fattore fuori-banda, poiché OTP e SMS risultano tra i dati intercettati con priorità

Indicatori di compromissione[Wrapper - luglio 2026]
SHA-256: 80be0942d0e20b5006e240434f42512c8b3cd0d54eee858a25663c1a4224a576
Package: tech.intel.dialer.updater

[Implant - luglio 2026]
SHA-256: feea425cde1223fe7afdd7a1ea631678ec6282f6cc20c3d3c0fb97cdbcf65b9b
Package: org.lenovo.storage.processor

[Implant primario]
SHA-256: e7abc375f24d0dd2419e0bce4686c7301b3ee82ae38906c67d3481580f6c648e
Package: tech.apple.dialer.scheduler

[Wrapper - maggio 2026]
SHA-256: 2884108b35eba7b8099087405653c1b23c3839f0d5058c4d61341fc31cfc6040
Package: org.honor.secure.helper

[Implant - maggio 2026]
SHA-256: 2fb5b01ea5a483d60b659e85327a53c6661bdd630d4afd93dc5fe0941d3ccbbe
Package: dev.huawei.media.helper

[Implant correlato]
SHA-256: 7c12f1237090e32c18583f66f1a9e44b029ad7c1e61179e1d524fb3093abd59a
Package: io.motorola.secure.executor

[Comandi bot principali]
remote_control - sessione schermo/webcam via WebRTC
get_logs - esportazione log accessibility
export_sms - esportazione SMS
export_calls - esportazione cronologia chiamate
export_contacts - esportazione contatti
export_file - raccolta file locali
send_sms - invio SMS dal dispositivo
ussd - esecuzione codici USSD
geo - attivazione geolocalizzazione
disable_gp - disattivazione Google Play ProtectFonte primaria: ThreatFabric Mobile Threat Intelligence. Report completo disponibile sul blog ufficiale di ThreatFabric.

Si parla di:

Toggle

Da due anni si spacciava per movimento hacktivista filo-palestinese. Il Dipartimento di Giustizia americano ha invece confermato ciò che gli analisti sospettavano da tempo: dietro il collettivo “#Handala” #opera il #Ministero dell’#Intelligence iraniano (#MOIS), e il suo bersaglio attuale sono i giornalisti israeliani, contattati su #WhatsApp e #Telegram con la stessa cura con cui si costruisce una fonte, per rubare loro le credenziali e, in alcuni casi, l’intero telefono.

Lo Shin Bet e l’Autorità nazionale per la cybersicurezza israeliana hanno diffuso il 16 agosto 2026 un avviso congiunto, raro per esplicitezza, in cui si afferma che “gli operativi dell’intelligence iraniana stanno tentando di raccogliere informazioni sensibili su sviluppi politici e di #sicurezza, ottenere accesso a fonti giornalistiche, materiali di lavoro e corrispondenza”. Non è un’allerta generica: arriva dopo mesi di segnalazioni da parte di redazioni come Haaretz, i cui cronisti sono stati impersonati per avvicinare colleghi e contatti.

Chi è davvero HandalaIl nome richiama la celebre vignetta del fumettista palestinese Naji al-Ali, e per due anni il brand “Handala Hack Team” ha coltivato un’immagine da collettivo hacktivista indipendente, rivendicando data breach e defacement contro obiettivi israeliani sui propri canali Telegram. È la stessa tattica di copertura vista in altri cluster iraniani — un layer “civile” che permette a #Teheran di condurre operazioni offensive negando plausibilmente il coinvolgimento statale, mentre online si costruisce consenso e narrativa a supporto della causa filo-palestinese.

A marzo 2026 il Dipartimento di Giustizia USA ha reso pubblica un’incriminazione che collega individui operanti sotto l’ombrello Handala al MOIS, inquadrando le loro attività in un più ampio programma di “operazioni psicologiche cyber-abilitate” — disinformazione, intimidazione e raccolta di intelligence combinate nello stesso apparato. Lo stesso ecosistema di attori legati a Teheran è stato osservato a marzo colpire con un wiper l’azienda Stryker e violare la casella di posta personale del direttore dell’FBI, segno di un’operatività che spazia dal sabotaggio industriale allo spionaggio mirato su singole persone.

Come funziona l’avvicinamentoLa campagna descritta da Shin Bet non punta a exploit zero-day, ma a ingegneria sociale paziente e su misura, costruita specificamente attorno al mestiere del giornalista. Gli operatori contattano il bersaglio fingendosi conoscenti, colleghi o addirittura firme note — tra i nomi usati come esca, secondo le ricostruzioni giornalistiche, anche quello del noto reporter Barak Ravid — con proposte di collaborazione, richieste di intervista o l’offerta di materiale esclusivo su sviluppi politici e militari, l’esca perfetta per chi vive di scoop.

Da lì si dipartono tre vettori distinti, spesso combinati nella stessa conversazione:

Link a pagine di login contraffatte che imitano Google, per catturare credenziali dell’account principale e, con esso, l’accesso a mail, contatti e cronologia dei documenti condivisi;

Link a Google Drive falsificati che rimandano a documenti “esclusivi” ma in realtà instradano verso pagine di raccolta credenziali identiche a quelle originali;

File malevoli inviati come allegati — presunti dossier, registrazioni o documenti di interesse — che una volta aperti concedono accesso completo al dispositivo mobile, inclusi messaggistica, microfono e geolocalizzazione.

L’obiettivo dichiarato dalle autorità israeliane non è solo la singola casella di posta: è la ricostruzione della rete di fonti del giornalista, l’accesso a materiali di lavoro non ancora pubblicati e, in prospettiva, la possibilità di alimentare operazioni di influenza usando conversazioni sottratte, come già avvenuto in altri episodi in cui gruppi legati a Teheran hanno pubblicato messaggi privati rubati per screditare bersagli israeliani.

Perché conta per chi si occupa di difesaIl caso Handala è un promemoria scomodo per chi lavora in redazioni, ONG e uffici stampa che trattano materiale sensibile su Medio Oriente: l’anello debole non è quasi mai l’infrastruttura tecnica, ma la fiducia interpersonale che il mestiere stesso richiede di concedere a sconosciuti. Un attaccante di livello statale che parla la lingua del settore — propone uno scoop, cita eventi reali, imita lo stile di un collega — supera in un colpo solo gran parte delle difese tecniche standard, perché la vittima interagisce volontariamente con il contenuto malevolo.

Per i team di sicurezza che proteggono realtà editoriali o organizzazioni esposte, le raccomandazioni diffuse da Shin Bet restano il primo presidio praticabile:

Verificare l’identità di chi propone collaborazioni o interviste tramite un canale separato da quello di primo contatto, prima di aprire qualunque link o allegato;

Non inserire mai credenziali dopo aver seguito un link ricevuto in chat, per quanto il mittente sembri legittimo — meglio digitare manualmente l’indirizzo del servizio;

Attivare l’autenticazione a due fattori tramite app authenticator (non SMS) su tutti gli account di posta e cloud storage;

Impostare indirizzi di recupero account separati e monitorati;

Segmentare i dispositivi usati per il lavoro giornalistico da quelli personali, quando possibile, e mantenere aggiornati i sistemi operativi mobili.

Handala dimostra ancora una volta come i confini tra hacktivismo, spionaggio statale e guerra dell’informazione si siano ormai dissolti: lo stesso gruppo che rivendica breach “per la causa” su Telegram può, il giorno dopo, star raccogliendo materiale per un dossier destinato ai servizi. Per i difensori, l’unica postura sensata è trattare ogni contatto non sollecitato — anche il più credibile — come potenzialmente ostile.

Indicatori e riferimentiAttore: Handala (Handala Hack Team) — collegato al MOIS iraniano
Vettori: WhatsApp, Telegram
TTP: impersonificazione di giornalisti/contatti noti, phishing credenziali Google,
Google Drive link contraffatti, allegati malevoli per compromissione mobile
Target: giornalisti e figure pubbliche israeliane (es. redazioni come Haaretz)
Incriminazione USA: marzo 2026 (Dipartimento di Giustizia, MOIS)
Allerta ufficiale: Shin Bet + National Cyber Directorate, 16 agosto 2026
Canale di segnalazione IL: hotline 119 (National Cyber Directorate)

Si parla di:

Toggle

Il 5 agosto una campagna coordinata di #vishing potenziato da sistemi LLM ha colpito in un solo giorno quattro dei fondi speculativi più blindati di Wall Street: Citadel, Point72, Two Sigma e Millennium Management, oltre ad alcune società di private equity rimaste anonime. Voci clonate di dirigenti ed executive hanno telefonato a dipendenti selezionati chiedendo credenziali e accessi ai sistemi interni. Non è la tecnica a essere nuova — il voice cloning in tempo reale è disponibile ai criminali informatici da anni — è la scelta dei bersagli a segnare un punto di svolta: quando conviene economicamente attaccare simultaneamente le difese più sofisticate del settore finanziario, significa che il costo dell’attacco è crollato più velocemente della capacità difensiva della maggior parte delle aziende.

Cosa è successo il 5 agostoSecondo quanto riportato da InvestmentNews e ripreso da Bloomberg, gli attaccanti hanno usato tecnologia di sintesi vocale per replicare tono, cadenza e fraseggio di executive e colleghi fidati, tentando di convincere i dipendenti a cedere credenziali o concedere accesso alle reti interne. Two Sigma, che gestisce circa 75 miliardi di dollari di asset, ha dichiarato di aver rilevato e bloccato il tentativo prima che causasse danni: “Il nostro team di #sicurezza ha risposto rapidamente a una campagna di vishing rivolta a Two Sigma e ad altri gestori di investimenti, e non abbiamo riscontrato alcun impatto sui nostri dati o sistemi.” Point72 ha informato i propri investitori dell’attacco, precisando che una prima revisione non ha rilevato furti di dati dei clienti, mentre le indagini proseguono. Citadel e Millennium Management non hanno commentato se le loro difese abbiano retto, lasciando aperta la domanda su cosa sia realmente accaduto dietro le quinte.

Perché colpire proprio gli hedge fundVinod Paul, presidente di Align Managed Services (società di #cybersecurity specializzata in clienti hedge fund), ha sintetizzato il cambiamento in termini puramente economici: “Prima potevano attaccare 50 entità in un attacco mirato, ora possono farne 1.000.” È la logica di scala che ha reso conveniente includere anche i bersagli più difficili in una campagna che, tanto, costa quasi nulla anche quando fallisce su centinaia di target minori. Anche un solo successo contro un’istituzione delle dimensioni di Citadel giustifica l’intero investimento operativo.

Ma c’è una ragione strutturale, non solo economica, per cui gli hedge fund sono bersagli particolarmente vulnerabili al vishing basato su sistemi computazionali LLM: la cultura organizzativa di queste aziende è costruita attorno a decisioni rapide e guidate dall’autorità gerarchica. In ambienti di trading ad alta frequenza, la velocità ha un valore economico diretto, e i dipendenti sono addestrati a eseguire le istruzioni di un dirigente senza attrito procedurale eccessivo. È esattamente questa deferenza operativa — l’istinto di agire subito quando chiama una voce riconosciuta come autorevole — la leva psicologica che il vishing basato su sistemi LLM sfrutta. Un clone vocale non deve essere perfetto: deve solo generare fiducia sufficiente a sospendere lo scetticismo normale.

Non un episodio isolato: il precedente UNC3753 / Luna MothLa campagna del 5 agosto non nasce nel vuoto. A giugno 2026 #Mandiant (#Google) aveva documentato una campagna di vishing sostenuta condotta dal cluster di minaccia UNC3753 — tracciato anche come Luna Moth o Silent #Ransom Group — contro decine di studi legali, società di servizi professionali e istituzioni finanziarie tra gennaio e maggio 2026. Quella campagna spingeva oltre la semplice telefonata: in alcuni casi gli attaccanti si sono presentati fisicamente negli uffici delle vittime spacciandosi per personale IT di supporto, un ibrido di ingegneria sociale digitale e fisica che, secondo le fonti, non risulta replicato nell’attacco del 5 agosto contro gli hedge fund. Resta però il segnale di una tendenza: gruppi come Luna Moth hanno costruito un intero modello operativo attorno all’impersonificazione vocale e all’inganno diretto del personale, senza bisogno di esche di phishing tradizionali o #malware da distribuire.

Il precedente da 25,6 milioni di dollariIl caso che ha reso il settore consapevole della portata del rischio risale al 2024: un dipendente finanziario della filiale di Hong Kong di Arup, multinazionale di ingegneria, fu convinto a trasferire circa 25,6 milioni di dollari in più tranche dopo aver partecipato a una videoconferenza in cui ogni altro partecipante — incluso il presunto CFO dell’azienda — era in realtà un deepfake generato con sistemi LLM. Quell’episodio resta il punto di riferimento per capire fin dove può spingersi un attacco di impersonificione sintetica quando la vittima non ha protocolli di verifica indipendenti dal canale stesso su cui arriva la richiesta.

FINRA Fusion Center: il primo vero collaudoL’attacco del 5 agosto ha attivato per la prima volta in scenario reale il Financial Intelligence Fusion Center di FINRA, il portale di condivisione di threat intelligence quasi in tempo reale lanciato il 31 marzo 2026 nell’ambito dell’iniziativa “FINRA Forward”. Il regolatore non ha commentato pubblicamente i dettagli dell’incidente specifico, ma la sua attivazione rappresenta il primo test operativo documentato della piattaforma contro un attacco coordinato e in corso sul settore che è chiamata a proteggere. Il valore di uno strumento come questo sta nell’effetto rete: un attacco simultaneo contro più aziende genera intelligence collettiva che nessuna singola firma potrebbe produrre da sola.

Sullo sfondo normativo pesano anche gli emendamenti SEC del 2024 al Regulation S-P (la “Safeguards Rule”), che impongono a tutti i consulenti di investimento registrati SEC di mantenere programmi scritti di risposta agli incidenti e di notificare i clienti coinvolti entro 30 giorni da una violazione confermata. La SEC ha inserito la conformità a Regulation S-P tra le priorità di verifica per l’anno fiscale 2026, dopo aver già sanzionato per 325.000 dollari una società di consulenza per la mancanza di un programma scritto di sicurezza informatica in seguito a un incidente di account takeover via email.

La difesa che funziona: verifica fuori bandaGli esperti del settore convergono su un’unica raccomandazione concreta: la verifica out-of-band. Quando arriva una chiamata che richiede un’azione sensibile — trasferimento di credenziali, autorizzazione di accesso a un sistema, disposizione di un bonifico — il dipendente deve riagganciare e ricontattare in modo indipendente l’interlocutore su un canale separato e già verificato in precedenza, richiedendo un’autenticazione che un clone vocale non può replicare in tempo reale.

Adottare parole d’ordine concordate privatamente in anticipo, mai pronunciate in canali registrabili o accessibili pubblicamente, da richiedere prima di qualunque azione ad alto rischio.

Imporre protocolli di callback su un numero verificato indipendentemente, non su quello fornito dal chiamante.

Applicare la policy in modo universale: un dirigente che aggira le proprie procedure di verifica per comodità crea la falla che gli attaccanti sfruttano.

Integrare la formazione del personale con simulazioni realistiche di vishing basato su sistemi computazionali, non solo con esercitazioni di phishing via email.

Valutare l’adesione a piattaforme di condivisione di threat intelligence settoriali (in Italia, ad esempio, i CERT di settore e i framework di information sharing bancari e finanziari) per ricevere IoC e pattern di attacco in tempo utile.

Come ha osservato Charles Failla, CEO di Sovereign Financial Group, “una sicurezza scadente è comunque scomoda — è solo scomoda tutta insieme, più avanti.” La frizione di un callback di trenta secondi è enormemente più economica del costo di un bonifico fraudolento da otto cifre. Per i responsabili sicurezza italiani che seguono realtà finanziarie o gestiscono clienti enterprise con forte cultura gerarchica, il caso Wall Street è un promemoria diretto: la protezione contro il vishing basato su sistemi computazionali non è (più) un problema tecnologico da delegare al perimetro, ma un problema di processo organizzativo da imporre dall’alto, inclusi i dirigenti stessi.

Migliaia di email di conferma iscrizione e newsletter che intasano la casella di posta in pochi minuti, seguite — puntuale come un copione — da un messaggio Teams di un fantomatico “IT Support” pronto ad aiutare. È la sequenza che eSentire’s Threat Response Unit (TRU) ha documentato in una campagna di luglio 2026 contro un’azienda del settore software, attribuita al broker di accessi iniziali UNC6692. Il bersaglio finale non è un semplice furto di credenziali: è l’installazione di Edgecution, un’estensione malevola per Microsoft Edge capace di evadere la sandbox del browser e prendere il controllo dell’host sottostante.

UNC6692 non è un nome nuovo per chi segue il crimine informatico organizzato: Google Cloud/Mandiant lo ha già descritto come un initial access broker (IAB) che prepara il terreno per gruppi ransomware, tra cui la syndicate nota come Payouts King. La catena osservata da eSentire — email bombing, impersonificazione IT via Teams, Quick Assist e una suite di malware modulare battezzata “SNOW” — è la stessa tradecraft già segnalata da Google e da The Hacker News nei mesi scorsi, ma il report più recente aggiunge dettagli tecnici granulari sull’ultimo anello della catena, l’estensione Edgecution, e sui suoi indicatori di compromissione.

Fase 1: sommergere la vittima di email per giustificare una chiamataL’attacco si apre con una tecnica ormai da manuale ma sempre efficace: l’email bombing. Iscrivendo l’indirizzo della vittima a migliaia di newsletter e servizi di conferma automatica, gli attaccanti saturano la casella di posta in pochi minuti. L’obiettivo non è nascondere altro traffico, ma costruire un pretesto plausibile: un dipendente sommerso da email è più propenso ad accettare senza troppe domande il contatto di un “supporto IT” che offre di risolvere il problema.

Subito dopo il bombing, gli attaccanti contattano la vittima su Microsoft Teams impersonando l’identità “IT Support | Corporate IT Service (Internal)”. La scelta del canale non è casuale: Teams è percepito come un ambiente aziendale “fidato” rispetto alla posta elettronica, il che abbassa ulteriormente la soglia di sospetto della vittima nel momento cruciale.

Fase 2: Quick Assist come porta d’accesso hands-onIl finto tecnico guida la vittima a lanciare Quick Assist, lo strumento di assistenza remota integrato in Windows, dando agli attaccanti accesso interattivo alla macchina. Da quel momento sono loro a dirigere l’infezione: portano la vittima su un sito di phishing ospitato su Amazon S3 e progettato per imitare una pagina Office 365. La pagina utilizza i primi due pulsanti per far scaricare alla vittima AutoHotkey e uno script stager, mentre un modulo di login raccoglie in chiaro la password Office 365 non appena viene premuto “invio”. Un dettaglio curioso della catena: lo script analizza persino gli appunti (clipboard) della vittima con un’espressione regolare, alla ricerca di un codice di riferimento fornito verbalmente durante la finta sessione di supporto — un ulteriore livello di “autenticazione sociale” della truffa.

Edgecution: un’estensione Edge che rompe il sandbox del browserIl payload finale, Edgecution, combina un’estensione malevola per Microsoft Edge con un native messaging host in Python. È proprio questa combinazione a permettere all’estensione — normalmente confinata alla sandbox del browser — di comunicare con un processo nativo sul sistema operativo e, di fatto, evadere i limiti imposti dal browser stesso. Una volta installata, Edgecution è in grado di monitorare in tempo reale i siti web visitati dalla vittima, catturare le credenziali Office 365 inserite, scrivere file arbitrari sul disco, enumerare i processi in esecuzione ed eseguire comandi shell, Python o PowerShell a piacimento — di fatto un accesso remoto completo mascherato da componente del browser.

Lo stager scaricato dal sito S3 arriva come archivio ZIP protetto da password, estratto tramite tar.exe in una sottocartella nascosta dentro %LOCALAPPDATA%\Microsoft\Edge\User Data. Tutte le stringhe presenti nello stager e nel native messaging host sono offuscate con XOR e decodificate solo a runtime, un accorgimento pensato per rallentare l’analisi statica. Per la persistenza, il malware scrive voci di registro sotto la chiave NativeMessagingHosts di Microsoft Edge e crea — eseguendolo immediatamente — un’attività pianificata configurata per rilanciare Edge con l’estensione caricata a ogni accesso.

Un IAB al servizio del ransomwareIl quadro attributivo colloca UNC6692 non come gruppo ransomware in sé, ma come specialista dell’accesso iniziale che poi rivende o passa il testimone a operazioni di estorsione più ampie, in particolare Payouts King. È un modello di business ormai consolidato nell’ecosistema del cybercrime: separare chi entra da chi cifra e negozia il riscatto permette a entrambe le parti di specializzarsi e di essere più difficili da tracciare come un’unica organizzazione. Vista in quest’ottica, la sofisticazione dell’ingegneria sociale di UNC6692 — pretesto costruito ad arte, canale Teams “aziendale”, Quick Assist, verifica via clipboard — non è fine a se stessa: è l’investimento necessario per garantirsi l’accesso di alta qualità che un cliente ransomware è disposto a pagare.

Due righe per i difensoriPer i team blue team, la catena UNC6692 offre diversi punti di intercettazione prima che si arrivi a Edgecution. Il primo è comportamentale: un’ondata improvvisa di iscrizioni a newsletter verso una singola casella dovrebbe generare un alert automatico, così come un contatto Teams esterno o appena creato che si presenta come “IT Support” — Microsoft Teams consente di etichettare gli account esterni, e questa etichetta va monitorata, non ignorata dagli utenti. Il secondo punto di controllo è tecnico: le policy aziendali dovrebbero limitare l’uso di Quick Assist ai soli casi avviati dall’help desk interno tramite ticket, bloccandolo o quantomeno alertando su ogni sessione avviata da un utente su richiesta esterna. Sul fronte endpoint, vale la pena monitorare la creazione di voci sotto HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts e la creazione di scheduled task che rilanciano msedge.exe con parametri di estensione custom, oltre a restringere via policy quali estensioni Edge possono essere installate al di fuori dello store ufficiale.

Va sottolineato che, secondo eSentire, l’archivio ZIP di Edgecution viene ricostruito da byte “spogliati” dell’header standard, un dettaglio che rende la sua individuazione tramite semplice controllo di firma file inefficace: servono euristiche comportamentali o EDR capaci di ispezionare i native messaging host registrati, non solo le estensioni installate nel browser.

Indicatori di compromissione[Infrastruttura C2 Edgecution - domini CloudFront]
d385m5skczp5q5.cloudfront[.]net
d7xpwoah6gdv2.cloudfront[.]net
(+ 5 domini CloudFront aggiuntivi identificati da eSentire TRU)
[URL di delivery phishing/payload - Amazon S3]
hxxps://app7040.s3.us-east-1.amazonaws[.]com/patch.html
hxxps://app5805.s3.us-east-1.amazonaws[.]com/js/patch3265343.a
(+ 3 URL aggiuntivi identificati da eSentire TRU)
[Hash SHA-256 - artefatti sito phishing e payload]
232bca658c585627830623fcdce56647dc291666b25c901ee56212681198067a
e88c196a86c74ea0e53dfe77c93f577cb441ee590756cf7f3284522a2d6a6be5
da1cf68c9dc1cebcebf8ec7d1cf99ac9c0291db7b21bf279b9cad24c7a49948c
[Comandi osservati in fase di deployment]
tar.exe -xf ".zip" -C "%LOCALAPPDATA%\Microsoft\Edge\User Data\test1" --passphrase ""
cmd.exe /c python --version 2>&1
cmd /c start /min ... & del
[Account Microsoft Teams usati per l'impersonificazione IT]
Identità display: "IT Support | Corporate IT Service (Internal)"
(indirizzi email specifici omessi dalla fonte originale)
[Persistenza]
Chiave di registro: HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts
Meccanismo: Scheduled Task creato ed eseguito immediatamente per rilanciare Microsoft Edge con l'estensione caricataFonti: eSentire Threat Response Unit (TRU), Google Cloud Threat Intelligence/Mandiant, The Hacker News, BleepingComputer.