Una nuova famiglia malware denominata SynkLoader combina phishing su Microsoft Teams, esecuzione PowerShell in memoria, un runtime Python autonomo, caricamento manuale di DLL, persistenza attraverso task pianificati e un falso blocco di Windows progettato per rubare la password dell’utente. L’operazione non si ferma alle credenziali: gli attaccanti possono aprire un tunnel dalla macchina compromessa verso i sistemi interni, impartire comandi PowerShell e controllare il desktop tramite VNC. Expel ha scoperto la catena durante un incidente reale e ha ingannato il server di comando simulando una grande rete aziendale, inducendo gli operatori a consegnare una parte significativa del proprio arsenale.
Cosa leggere
Il falso tecnico IT usa Microsoft Teams per consegnare SynkLoader
L’attacco individuato il 18 agosto 2026 parte da un contatto su Microsoft Teams proveniente da un indirizzo nel formato <username>@<company>.onmicrosoft.com, dominio predefinito assegnato alle organizzazioni Microsoft 365. L’operatore utilizza il nome visualizzato “IT Service Desk” e si presenta come un membro dell’assistenza aziendale. Expel non ha recuperato l’intera conversazione, ma i metadati mostrano che la vittima è stata convinta a scaricare un pacchetto MSI da un endpoint Microsoft Azure Blob Storage. L’indirizzo apparteneva realmente all’infrastruttura cloud di Microsoft, ma il contenitore era controllato dagli attaccanti: una distinzione essenziale, perché il dominio del fornitore non garantisce la legittimità del contenuto ospitato. Il file 331.msi si presenta come un’applicazione denominata PowershellCleaner, descritta come una presunta utility per ripulire o correggere PowerShell. Il dipendente non viene quindi indirizzato verso un exploit invisibile, ma guidato a installare personalmente quello che crede essere uno strumento dell’helpdesk. La tecnica replica uno schema ormai consolidato nel quale la chat aziendale offre più credibilità di una normale email, perché il messaggio appare nel luogo in cui dipendenti e tecnici discutono quotidianamente di problemi operativi.

Una dinamica molto simile caratterizzava A0Backdoor, distribuita attraverso tecnici falsi e richieste di assistenza su Teams, dove gli attaccanti combinavano impersonificazione dell’helpdesk, installer MSI e strumenti legittimi di supporto remoto. SynkLoader elimina la necessità di assumere immediatamente il controllo grafico della macchina e induce invece la vittima a stabilire autonomamente il primo punto d’appoggio. La campagna dimostra inoltre perché i domini onmicrosoft.com non possano essere trattati come automaticamente affidabili: qualsiasi tenant Microsoft 365 può ottenere un indirizzo di questo tipo e utilizzarlo per dare a un’identità esterna un’apparenza aziendale. I controlli devono considerare relazione tra tenant, provenienza del contatto, reputazione dell’account e comportamento richiesto, soprattutto quando un interlocutore sconosciuto invita a scaricare software o eseguire procedure amministrative.
L’MSI nasconde PowerShell e installa un ambiente Python completo
Dopo l’avvio, il pacchetto MSI estrae nella cartella %LocalAppData%\PowershellCleaner\script un archivio denominato archive6.zip e lo script cleaner.ps1, eseguito automaticamente dall’installer. Il primo comando apre una finestra PowerShell nascosta e ricostruisce il codice attraverso l’espressione -join [char[]], convertendo una sequenza di valori esadecimali in una stringa successivamente passata a Invoke-Expression. Il livello ottenuto contiene un blocco Base64 cifrato con AES-CBC, che viene decodificato, decifrato e trasformato dinamicamente in uno ScriptBlock tramite System.Management.Automation.ScriptBlock::Create. Da quel momento il codice PowerShell opera in memoria, limitando gli artefatti che i controlli basati esclusivamente sui file possono acquisire. Lo script genera un nome alfanumerico casuale di 16 caratteri, crea una sottodirectory dentro %AppData% ed estrae l’archivio in una struttura annidata che termina con fl\ang. Qui si trova l’ambiente principale di SynkLoader: una copia ridotta ma completa del runtime Python, librerie precompilate, lo script malevolo ss.py e diverse DLL presentate come componenti del runtime Microsoft. Windows non include normalmente Python, quindi gli operatori distribuiscono pythonw.exe insieme al malware e non dipendono dalla configurazione della macchina bersaglio.

Il processo viene avviato senza console visibile, passando ss.py come argomento. La scelta produce una catena nella quale un MSI apparentemente amministrativo avvia PowerShell, che a sua volta prepara un interprete Python autonomo dentro una directory casuale del profilo utente. L’uso combinato di strumenti legittimi, dati cifrati e ambienti portabili ricorda DOUBLECUP, il Loader-as-a-Service che costruisce catene PowerShell eseguite prevalentemente in memoria, ma SynkLoader aggiunge una componente interattiva: il loader riceve dal C2 nuovo codice Python e lo esegue dinamicamente. L’incrocio tra linguaggi non rappresenta un virtuosismo fine a sé stesso. Passare da MSI a PowerShell, quindi a Python e successivamente a DLL C# o C++, frammenta gli indicatori tra più runtime e indebolisce i prodotti che osservano soltanto un singolo livello. Un precedente comparabile emerge nel RAT Windows distribuito tramite PowerShell, VBScript e un runtime Python mascherato, dove il cambio continuo di tecnologia serviva a rendere meno lineare la ricostruzione dell’infezione.
Il protocollo C2 usa ChaCha20 e trasforma Python in un esecutore remoto
Il loader principale contiene tre domini C2 codificati direttamente nello script: neversoftmain[.]net, rootfarmapp[.]net e tripinupdate[.]net. SynkLoader ne sceglie uno casualmente, costruisce un indirizzo che incorpora due token e l’identificatore della vittima e invia un beacon ogni 90-120 secondi. L’identificatore coincide con il nome casuale di 16 caratteri assegnato alla directory d’installazione, diventando il riferimento persistente utilizzato lungo l’intera catena. Le richieste includono timestamp, local_id e un campo che distingue i semplici ping dai risultati dei moduli. Il traffico viene cifrato con una versione modificata di ChaCha20: gli sviluppatori hanno sostituito le costanti Sigma standard con le stringhe mlswgtppayebtezk e lwifnrfiosmfrubf, utilizzando contemporaneamente l’identificatore della vittima come chiave. La personalizzazione non trasforma il protocollo in un sistema crittografico particolarmente sofisticato, ma ostacola strumenti e script che cercano implementazioni ChaCha20 convenzionali. Una volta decifrata la risposta, il loader passa il contenuto direttamente alla funzione exec di Python, permettendo agli operatori di eseguire codice arbitrario in memoria senza distribuire ogni volta un nuovo eseguibile. Expel ha sfruttato proprio questa caratteristica: dopo avere decodificato il protocollo, i ricercatori hanno costruito un emulatore capace di registrare i comandi invece di eseguirli e hanno inviato al C2 informazioni false, facendo apparire il sistema come parte di una grande infrastruttura Active Directory. La ricerca tecnica completa pubblicata da Expel spiega che il primo modulo ricevuto effettua una profilazione dettagliata della macchina. Il codice Python carica tramite CPython una DLL denominata msvcp150.dll, nome che imita le librerie del Microsoft Visual C++ Redistributable. Il file è in realtà un modulo C# dotato delle esportazioni RunPowerShell e RunPowerShellW, utilizzate per creare un oggetto PowerShell e impartire comandi senza avviare il normale eseguibile. Il malware recupera hostname, utente, privilegi, processi, servizi, dominio Active Directory, informazioni di sistema e numero di computer presenti nel dominio. Quest’ultimo dato risulta particolarmente importante, perché offre agli operatori una misura immediata della dimensione potenziale della vittima. La combinazione tra caricamento in memoria, offuscamento e moduli sostituibili segue la stessa logica dei servizi criminali come Cruciferra, progettato per nascondere RAT e infostealer agli antivirus e agli EDR: ridurre le firme statiche e spostare il rilevamento sul comportamento complessivo della catena.
La persistenza passa attraverso DLL in memoria e task creati via COM
Quando l’emulatore ha dichiarato di trovarsi all’interno di una rete con migliaia di sistemi Active Directory, il C2 ha consegnato quasi immediatamente un modulo di persistenza e un componente dedicato al phishing delle credenziali. Anche la persistenza attraversa più linguaggi. Un modulo Python carica msvcp160.dll, questa volta una libreria C++ nativa che implementa un manual DLL loader. La funzione esportata RunDllFunction riceve il contenuto di una DLL, le sue dimensioni e il nome della funzione da invocare, mappando il file direttamente nella memoria del processo. msvcp160.dll rimane presente sul disco e potrebbe quindi essere intercettata attraverso hash o firme, ma tutte le librerie successive possono essere eseguite senza essere salvate nel filesystem, riducendo i reperti disponibili per l’analisi forense tradizionale. Il modulo Python contiene infatti un’ulteriore DLL codificata in Base64, che viene caricata manualmente e invocata attraverso l’esportazione nm. Questa libreria installa la persistenza utilizzando l’interfaccia COM del Task Scheduler, attraverso CLSID_TaskScheduler e IID_ITaskService, invece di eseguire schtasks.exe o un comando PowerShell facilmente riconoscibile. La scelta permette di eludere le regole che cercano parole chiave nella riga di comando o la creazione di task da processi comunemente abusati. L’attività resta comunque osservabile attraverso telemetria COM, RPC, modifiche alle attività pianificate e relazione tra processo sorgente e task creato. SynkLoader assegna al task un nome alfanumerico casuale di 12 caratteri e configura due trigger: il primo viene attivato a ogni accesso dell’utente, mentre il secondo esegue il loader ogni giorno alle 10:00 locali. In entrambi i casi il task avvia ss.py tramite il pythonw.exe incluso nella cartella casuale. L’orario fisso potrebbe servire come meccanismo di recupero qualora il trigger al login fallisse, anche se Expel non ha stabilito una finalità certa. I percorsi PDB lasciati nelle DLL mostrano che più componenti sono stati compilati dall’utente Windows genry, collegando tecnicamente il falso runtime PowerShell e il modulo di persistenza. Il ricorso a task schedulati dopo un contatto su Teams ricorda la catena di UNC6692, che usava un falso supporto IT, tunneler Python e attività pianificate per mantenere la suite SNOW. SynkLoader segue lo stesso principio generale, ma tenta di nascondere l’operazione evitando gli strumenti da riga di comando più monitorati.
PhishLocker imita il blocco di Windows per rubare la password in chiaro
Il componente più originale della catena è stato denominato PhishLocker. Dopo oltre dodici ore di attesa, gli operatori hanno selezionato manualmente il falso sistema costruito da Expel e hanno inviato una DLL che genera un’interfaccia grafica a schermo intero quasi identica al blocco di Windows 11. Il modulo recupera il nome dell’utente tramite GetUserName, carica lo sfondo dalla directory C:\Windows\Web\Screen e presenta una finestra senza bordi con orologio, icone e campo password. La tecnica trasferisce sul desktop un modello di phishing storicamente utilizzato nei browser, quando pagine malevole potevano entrare a schermo intero e simulare l’interfaccia di un servizio. L’obiettivo non consiste nel bloccare o cifrare realmente il computer, ma nel convincere il dipendente che la sessione sia stata sospesa e richieda una nuova autenticazione. La password digitata viene consegnata agli attaccanti in chiaro, evitando strumenti molto sorvegliati come Mimikatz, il dump di LSASS o il recupero degli hash. In un’azienda che utilizza la stessa identità per Windows, VPN, Microsoft 365 e applicazioni protette da SSO, una password valida può offrire più possibilità di movimento laterale rispetto a un hash riutilizzabile soltanto contro determinati protocolli. PhishLocker contiene però errori che possono tradirlo. La versione osservata imita Windows 11 anche quando la macchina esegue Windows 10, non applica la normale sfocatura allo sfondo quando appare il campo password e non impedisce la visualizzazione del selettore Alt+Tab, sebbene riporti rapidamente in primo piano la finestra fraudolenta. Il malware non verifica neppure la correttezza della credenziale attraverso le API di autenticazione di Windows: qualsiasi stringa permette di chiudere la schermata. Questo difetto non riduce necessariamente l’efficacia, perché un utente convinto di trovarsi davanti al vero blocco inserirà probabilmente la propria password corretta al primo tentativo. La scelta di simulare un problema locale si inserisce nella stessa evoluzione dell’ingegneria sociale osservata con Operation BlueDash e le false sessioni Teams e Zoom usate per installare strumenti remoti: la vittima viene accompagnata dalla prima conversazione fino all’esecuzione tecnica, mentre ogni passaggio riproduce un’attività aziendale plausibile. Se una schermata sospetta compare dopo un intervento dell’helpdesk, l’utente non dovrebbe inserire ulteriori credenziali ma scollegare la macchina dalla rete e contattare il supporto attraverso un canale indipendente.
TrafficRedirector apre la rete interna e prepara l’attacco manuale
Dopo PhishLocker, il C2 ha consegnato TrafficRedirector, una soluzione di tunneling che funziona come backconnect proxy. Il modulo stabilisce una connessione in uscita verso il server degli attaccanti e attende istruzioni contenenti indirizzo IP e porta da raggiungere. Ogni richiesta viene quindi inoltrata attraverso l’interfaccia di rete della macchina compromessa, permettendo agli operatori di accedere a servizi pubblici usando l’indirizzo IP aziendale oppure di raggiungere sistemi disponibili soltanto sulla LAN. Questa capacità rende particolarmente pericolosa la password raccolta dal falso blocco: gli accessi possono apparire provenienti dalla normale postazione del dipendente, aggirando allowlist basate sull’IP, controlli geografici e alcuni meccanismi di analisi del rischio. Il modulo introduce il dominio C2 dondermicapp[.]net, distinto da quelli utilizzati dal loader principale. Successivamente gli operatori hanno distribuito una shell interattiva che riceve comandi in tempo reale e usa msvcp150.dll per eseguire PowerShell in memoria. Le istruzioni arrivano da un endpoint dedicato, mentre i risultati vengono accodati e trasmessi a un secondo percorso del C2. Poiché l’emulatore iniziale non supportava quel protocollo, la shell sembrava non funzionare; gli attaccanti hanno ripetuto l’invio oltre quindici volte prima di consegnare un modulo aggiuntivo, probabilmente nel tentativo di diagnosticare l’errore. Il nuovo componente, chiamato StreamMaster, realizza un server VNC inverso in Python. Anche in questo caso è la vittima ad aprire la connessione verso l’esterno, evitando la necessità di esporre una porta in ingresso. Il malware trasmette screenshot compressi con zlib e permette di inviare movimenti del mouse e input da tastiera alla sessione corrente. Non si tratta di Hidden VNC: l’utente può vedere cursore, finestre e operazioni effettuate dall’attaccante, caratteristica che aumenta il rischio di scoperta durante un’azione prolungata. I commenti molto estesi, grammaticalmente corretti e non riconducibili a progetti open source hanno portato Expel a ipotizzare che almeno parte del modulo sia stata prodotta con strumenti di vibe coding, ma questa resta un’inferenza e non una prova dell’impiego dell’intelligenza artificiale. L’insieme formato da password, tunnel, shell e controllo VNC trasforma SynkLoader da semplice downloader in una piattaforma per operazioni hands-on-keyboard, nella quale l’automazione prepara l’ambiente e un operatore umano decide come proseguire.
L’obiettivo finale potrebbe essere ransomware o vendita dell’accesso
Expel non ha identificato il gruppo responsabile né osservato il payload conclusivo. Dopo avere adattato l’emulatore alla shell interattiva, i ricercatori hanno registrato alcuni comandi di profilazione; gli operatori si sono poi accorti di non trovarsi in un ambiente reale e hanno interrotto la connessione. L’attribuzione resta quindi aperta. La presenza del campo AD_counter, utilizzato per contare i computer del dominio, indica però un interesse diretto per la dimensione dell’organizzazione. Questa informazione è particolarmente utile ai gruppi ransomware, che valutano numero dei sistemi, capacità di interruzione e potenziale economico prima di formulare una richiesta, ma può servire anche a un initial access broker incaricato di classificare e rivendere l’accesso. Expel assegna una confidenza bassa-media all’ipotesi che il toolkit appartenga a un operatore ransomware o a un broker collegato a questo mercato, senza attribuirlo a una famiglia specifica. SynkLoader possiede comunque le capacità necessarie a preparare entrambe le strade: inventario del dominio, persistenza, acquisizione della password, tunnel verso la LAN, esecuzione PowerShell, VNC e consegna modulare di codice. La progressione potrebbe condurre a esfiltrazione, furto di identità, distribuzione di ransomware o vendita della macchina già compromessa. Le tecniche di evasione non devono essere interpretate come invisibilità assoluta. Un’azienda può rilevare la relazione anomala tra Teams, il download di un MSI da Azure Blob, msiexec.exe, PowerShell nascosto, la creazione di una directory casuale in AppData, pythonw.exe eseguito da un percorso insolito, il caricamento di msvcp150.dll e msvcp160.dll, i beacon periodici e la creazione di task tramite COM. La fase successiva offre ulteriori segnali: una finestra a schermo intero che imita il blocco, nuovi domini C2, connessioni proxy e attività VNC nella sessione interattiva. Il caso Akira, che riavvia Windows in modalità provvisoria per disattivare EDR e Defender mostra quanto gli operatori ransomware investano nell’aggiramento delle difese prima di avviare la cifratura; SynkLoader sembra progettato per consegnare un accesso ugualmente profondo senza rivelare in anticipo il payload finale.
La difesa deve unire identità, endpoint e controllo dei canali collaborativi
Bloccare SynkLoader richiede una risposta che parta prima dell’esecuzione del file. Gli amministratori di Microsoft Teams devono limitare i contatti esterni alle organizzazioni realmente necessarie, controllare le federazioni con tenant sconosciuti e rendere evidenti agli utenti le conversazioni provenienti dall’esterno. Un tecnico non dovrebbe chiedere attraverso una chat non verificata di installare un MSI, scaricare file da un contenitore cloud o disattivare protezioni. Le procedure di supporto devono prevedere ticket riconoscibili e una verifica separata dell’identità del chiamante. Sul piano tecnico, Azure Blob Storage e gli altri servizi cloud non possono essere bloccati indiscriminatamente, ma i download eseguibili devono passare attraverso reputazione, sandboxing, proxy e controlli di contenuto. Le policy applicative possono impedire l’esecuzione di MSI e interpreti portabili da directory scrivibili dall’utente, mentre regole comportamentali dovrebbero intercettare PowerShell avviato da installer, stringhe ricostruite con -join [char[]], uso di Invoke-Expression, ScriptBlock dinamici e pythonw.exe eseguito da cartelle casuali in AppData. La telemetria del Task Scheduler deve comprendere le attività create tramite COM e non limitarsi alla ricerca di schtasks.exe. Un caricamento di DLL con nomi simili ai runtime Microsoft deve essere confrontato con firma, percorso e processo padre: msvcp150.dll o msvcp160.dll collocate accanto a un Python portabile dentro il profilo dell’utente costituiscono un’anomalia rilevante. Se PhishLocker è stato visualizzato, la password dell’utente deve essere considerata compromessa anche quando la schermata è stata chiusa con successo. Servono isolamento dell’endpoint, revoca delle sessioni, reimpostazione della password, controllo degli accessi SSO e verifica di eventuali autenticazioni provenienti dall’indirizzo della stessa macchina. La sola autenticazione multifattore riduce alcuni abusi, ma non elimina il rischio quando l’attaccante dispone di un tunnel interno, della sessione compromessa o della possibilità di interagire con il desktop. La lezione centrale di SynkLoader riguarda la frammentazione della visibilità: email e Teams mostrano l’identità, il proxy osserva il download, l’EDR registra PowerShell e Python, Active Directory rileva la ricognizione e la rete vede i beacon. Nessun singolo segnale descrive l’intera intrusione, ma la loro correlazione ricostruisce una catena che dal falso helpdesk può arrivare fino al controllo manuale dell’infrastruttura.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.









