TwinLoot trasforma Microsoft 365 in un centro di comando per attacchi alle reti aziendali

Un framework Python che vive nel cloud Microsoft

I ricercatori dell’Ontinue Cyber Defense Center hanno individuato TwinLoot, un framework malware modulare scritto in Python che porta il modello living off the land nel cloud. Il sistema non si limita a utilizzare strumenti già presenti su Windows: costruisce comando e controllo sfruttando servizi legittimi di Microsoft Azure e Microsoft 365.

La campagna era ancora attiva nel mese di luglio, quando sono stati recuperati i moduli del malware. L’attività è stata rilevata il 18 agosto 2026.

TwinLoot usa SharePoint Online e le Microsoft Graph API per scambiare comandi e dati, Microsoft Teams per ottenere accesso interattivo e Microsoft Edge per rendere più credibili le comunicazioni generate dal dispositivo compromesso. Il traffico può quindi confondersi con le normali attività di utenti e applicazioni aziendali.

I moduli Python erano protetti con PyArmor 9.2.5. Dopo la decrittazione della configurazione incorporata, è emersa un’architettura composta da più canali operativi, progettati per ridurre la visibilità dell’attaccante e mantenere il controllo anche dopo la compromissione iniziale.

SharePoint, Graph e Teams diventano l’infrastruttura C2

Il componente di comando e controllo utilizza SharePoint Online come punto di scambio, secondo il modello del dead drop: l’attaccante deposita comandi o dati in uno spazio cloud e il malware li recupera attraverso API Microsoft legittime.

Le Microsoft Graph API svolgono il ruolo di canale applicativo. Invece di collegarsi a un server sospetto o a un dominio con una reputazione negativa, TwinLoot interagisce con un’infrastruttura ampiamente presente nelle reti aziendali.

Il framework aggiunge poi l’infrastruttura TURN relay di Microsoft Teams. Questa tecnologia, normalmente destinata a facilitare le comunicazioni interattive, viene sfruttata per mantenere un collegamento operativo con il sistema infetto. Il risultato è un canale che può apparire coerente con il traffico generato da Teams, soprattutto quando viene analizzato senza correlare identità, endpoint e attività cloud.

Microsoft Edge contribuisce a mascherare ulteriormente le richieste Graph API. Il browser presente sul dispositivo della vittima viene utilizzato per trasportare le comunicazioni, mentre l’automazione browser e l’eventuale impiego di componenti headless rendono più difficile distinguere un’attività malevola da quella di un’applicazione aziendale.

Secondo la valutazione dei ricercatori, TwinLoot è il primo framework da loro osservato a riunire in un unico impianto il dead drop su Microsoft 365, l’abuso del relay TURN di Teams e il trasporto tramite browser.

Le capacità: credenziali, comandi e pivot nella rete interna

TwinLoot include un modulo per il furto delle credenziali Windows. Il malware mostra una schermata di blocco falsa, costruita per assomigliare a quella legittima del sistema operativo, e chiede all’utente di inserire la password.

La raccolta avviene anche quando il tentativo fallisce. In caso di credenziale errata, la vittima visualizza un messaggio compatibile con un normale errore di autenticazione e può riprovare. Se l’inserimento successivo ha successo, il comportamento anomalo può non essere evidente.

Questa logica consente di acquisire password senza produrre necessariamente segnali facilmente riconoscibili dall’utente. Richieste inattese di autenticazione o schermate di blocco comparse fuori dal normale flusso operativo sono quindi elementi da verificare, soprattutto se si ripetono.

Il framework permette inoltre di eseguire comandi arbitrari sul sistema compromesso. L’attaccante può così raccogliere informazioni, modificare il comportamento dell’endpoint e preparare ulteriori attività.

Il componente più rilevante per il movimento laterale è un proxy interattivo SOCKS5. Il proxy instrada il traffico attraverso il processo infetto e può consentire di raggiungere risorse della rete interna non direttamente esposte su Internet. Un singolo computer compromesso diventa così un punto di pivot per ricognizione, accesso ad altri sistemi e interazione con servizi aziendali.

Persistenza senza privilegi amministrativi

TwinLoot adotta anche una tecnica di persistenza denominata dai ricercatori “Corrupting the Hive Mind”. Il metodo crea offline un hive di profilo obbligatorio, o mandatory profile hive, utilizzando API Windows legittime.

La tecnica non richiede privilegi amministrativi e non modifica direttamente il Registro di sistema durante l’installazione. Di conseguenza, può non generare gli eventi normalmente associati a una modifica del Registro o a un’operazione di elevazione dei privilegi.

Questo riduce la validità di alcune regole di rilevamento tradizionali. Un’organizzazione che cerchi soltanto chiavi di Registro alterate, processi amministrativi o attività con privilegi elevati potrebbe non intercettare la persistenza.

Ontinue descrive questo comportamento come il primo uso malevolo osservato in attività reali di tale metodo. La persistenza sfrutta funzionalità native del sistema operativo e lascia una traccia operativa più ridotta rispetto a tecniche basate su modifiche evidenti alla configurazione.

Preparazione accurata, ma attribuzione ancora incerta

L’architettura osservata indica una preparazione durata sette settimane. Prima dell’impiego operativo sarebbero stati predisposti due domini scaduti, un’applicazione Azure AD dedicata e un sito SharePoint destinato al ruolo di dead drop.

Nel framework Python è stato inoltre integrato uno strumento presentato originariamente durante una conferenza tecnologica. I domini risultavano preparati alcune settimane prima del resto dell’infrastruttura.

Non è stata attribuita l’operazione a un gruppo specifico. Il livello di integrazione tra offensive security, Python, identità cloud e servizi Microsoft rende plausibile il coinvolgimento di un operatore professionale oppure di uno sviluppatore con competenze avanzate sull’ecosistema Azure e Microsoft 365.

Non sono state rese note le versioni dei prodotti Microsoft coinvolte, né indirizzi IP, domini utilizzati, hash o altri indicatori puntuali. Non sono inoltre riportati identificativi CVE, un punteggio CVSS o una presenza nel catalogo KEV della CISA; non sono quindi disponibili una data di inserimento o una scadenza di mitigazione KEV da indicare.

Come cercare TwinLoot senza affidarsi solo agli indicatori

Il traffico verso Microsoft 365 non può essere considerato affidabile per definizione. La difesa deve concentrarsi sulle deviazioni dal comportamento atteso di utenti, dispositivi, applicazioni e servizi.

Le organizzazioni dovrebbero costruire baseline per SharePoint, Teams e Graph API, tenendo conto di volumi, frequenza, orari, destinazioni e modalità di accesso. Sequenze insolite di chiamate Graph, soprattutto se associate a un account o a un dispositivo che normalmente non le esegue, meritano un’indagine.

È necessario controllare anche le applicazioni OAuth e le concessioni di consenso Azure AD. Applicazioni inattese, autorizzazioni sproporzionate o nuove integrazioni con SharePoint e Graph possono indicare la preparazione del canale C2.

La telemetria di SharePoint e Teams va correlata con quella degli endpoint. Siti, file, sessioni relay e flussi di comunicazione anomali acquistano significato soprattutto quando coincidono con l’uso insolito di Edge, automazione browser, script Python o moduli protetti con PyArmor.

Le regole di rilevamento devono includere anche richieste ripetute di autenticazione, schermate di blocco inattese e tentativi di accesso falliti seguiti da un’autenticazione riuscita. Nel caso di TwinLoot, l’errore inserito dall’utente può essere già stato raccolto.

Infine, è opportuno cercare segnali compatibili con un proxy SOCKS5, connessioni interattive non previste e accessi a risorse interne provenienti da endpoint che normalmente non svolgono attività di amministrazione o pivoting. La correlazione tra identità, cloud ed endpoint è essenziale: analizzare separatamente questi tre livelli lascia ampi spazi all’attaccante.