C2Looper: come funziona il backdoor per Windows che sfrutta HTTP, GitHub e OneDrive

Le due versioni osservate di C2Looper

La prima versione: comando e controllo via HTTP

I campioni iniziali comunicano con un server controllato dagli attaccanti tramite HTTP in chiaro e usano messaggi in formato JSON. Secondo i report, il malware effettua interrogazioni molto frequenti, anche a intervalli di circa un secondo: un comportamento potenzialmente riconoscibile nei log di rete o nella telemetria degli endpoint.

Il beacon identifica la vittima attraverso dati come:

• nome utente di Windows;
• hostname DNS;
• identificativo del processo C2Looper in esecuzione;
• un bot ID derivato dall’hostname e dal nome utente.

Il beacon viene inviato al percorso /api/beacon, mentre l’output dei comandi viene restituito tramite /api/result/.

Il set di comandi offre all’operatore un controllo concreto sul sistema compromesso e comprende:

• esecuzione arbitraria di comandi di shell o di sistema;
• ricognizione dell’host;
• download di file;
• aggiornamento dell’impianto e distribuzione di payload aggiuntivi.

Particolarmente significativo è il comando upload. In una procedura osservata, C2Looper scarica un eseguibile portabile da un URL fornito dall’operatore e lo salva come DLL nella cartella locale di OneDrive dell’utente. Il malware può poi terminare il processo OneDrive e sfruttare un eseguibile legittimo di OneDrive per caricare la libreria inserita tramite DLL sideloading. Nei campioni analizzati è stata indicata la DLL wtsapi32.dll nel percorso %LocalAppData%\\Microsoft\\OneDrive.

La tecnica consiste nel collocare il codice malevolo accanto a un eseguibile affidabile e nel fare leva sul normale comportamento di caricamento delle librerie di Windows. Per questo, non basta rilevare la presenza di OneDrive: è più importante verificare se un binario legittimo di OneDrive carica una DLL inattesa da una posizione insolita o scrivibile dall’utente.

Offuscamento e tecniche di evasione

C2Looper utilizza la decrittazione XOR delle stringhe durante l’esecuzione, con una chiave di otto byte che secondo i report viene riutilizzata. Risolve inoltre dinamicamente le API di Windows tramite LoadLibrary e GetProcAddress. Questi accorgimenti possono rendere meno efficace una semplice analisi statica e aumentano il valore della telemetria comportamentale raccolta dagli strumenti EDR.

La versione più recente: GitHub come infrastruttura C2

La build più recente abbandona il modello basato su un server C2 convenzionale e usa repository GitHub per le attività di comando, beaconing, raccolta dei risultati e, secondo i report sulla nuova variante, gestione dei dati collegati ai payload.

A ogni host infetto viene assegnata una directory dedicata nel repository. L’impianto legge le istruzioni dal file cmd.json, esegue l’azione richiesta e scrive l’output nel file result.json della stessa directory.

L’uso di GitHub può complicare le strategie basate sul semplice blocco dei domini, perché il servizio è anche una piattaforma legittima usata da sviluppatori e aziende. La risposta più efficace è quindi comportamentale: occorre analizzare gli accessi periodici ai repository o alle API GitHub provenienti da endpoint che normalmente non ne hanno bisogno e distinguere l’attività JSON sospetta dagli usi autorizzati di sviluppo o CI/CD.

Il passaggio a GitHub e l’aggiunta di nuove capacità di esecuzione dei payload indicano che C2Looper è ancora in fase di sviluppo attivo.

Il possibile ingresso: campagne di social engineering ClickFix

ThreatLabz valuta con confidenza bassa o media la possibilità che C2Looper venga distribuito attraverso una catena d’infezione ClickFix composta da più fasi. In questo tipo di campagna, la vittima visualizza un falso messaggio di verifica, un errore del browser, un CAPTCHA o un avviso di riparazione del sistema. Il messaggio la induce quindi a copiare ed eseguire un comando in PowerShell, nella finestra Esegui di Windows o in un’altra interfaccia.

Il punto debole non è soltanto tecnico: è anche l’interazione umana. Una pagina web o un messaggio del browser non dovrebbe mai chiedere di incollare comandi in PowerShell, Terminale o nella finestra Esegui per completare una verifica o risolvere un problema.

I report sul più ampio ecosistema di social engineering citano anche il vishing tramite Microsoft Teams e l’abuso di Quick Assist. Le informazioni disponibili, tuttavia, non dimostrano che ogni campagna di questo tipo abbia distribuito C2Looper: i collegamenti vanno considerati un contesto plausibile, non un’attribuzione confermata.

Cosa monitorare

Le organizzazioni possono concentrarsi su alcuni comportamenti ad alto valore invece di tentare di bloccare indiscriminatamente ogni servizio associato al malware:

• Beaconing HTTP in chiaro: analizzare traffico JSON POST insolitamente regolare, in particolare richieste verso percorsi simili a /api/beacon e /api/result/, correlato con processi nuovi o sospetti.
• Attività GitHub anomala: cercare accessi degli endpoint a repository o API GitHub con periodicità insolita e directory per host che contengono cmd.json e result.json. GitHub non dovrebbe essere bloccato indiscriminatamente: è necessario tenere conto dei flussi legittimi di sviluppo e automazione.
• DLL sideloading tramite OneDrive: generare alert quando un eseguibile legittimo di OneDrive viene avviato da un percorso insolito del profilo utente, carica una DLL da una directory adiacente e scrivibile o crea processi figli inattesi.
• Esecuzione di comandi e ricognizione: usare la telemetria EDR per individuare PowerShell, cmd.exe, attività dalla finestra Esegui, discovery del sistema, download a più fasi ed esecuzione di shell da binari appena comparsi.
• Comportamento dell’impianto Rust: valutare insieme risoluzione dinamica delle API, stringhe cifrate, polling di rete e distribuzione dei payload, invece di affidarsi a una singola caratteristica del file.

Priorità di prevenzione

I controlli tecnici devono essere affiancati da misure contro il social engineering. Ove compatibile con le esigenze operative, le aziende dovrebbero limitare o governare PowerShell avviato dagli utenti, gli interpreti di script, i binari non firmati e l’esecuzione da directory scrivibili dall’utente. L’application allowlisting può ridurre ulteriormente la possibilità che un payload scaricato venga eseguito.

È inoltre essenziale formare dipendenti e personale dell’help desk: un sito web, un CAPTCHA, una pagina che mostra un errore del browser o un contatto di supporto non richiesto non dovrebbe mai chiedere di incollare comandi. Gli strumenti di assistenza remota devono essere gestiti tramite procedure approvate, canali verificati, autenticazione forte, registrazione delle sessioni e revisione rapida degli accessi insoliti.

Segmentazione della rete, principio del minimo privilegio, autenticazione multifattore, aggiornamento tempestivo dei sistemi esposti a Internet e backup offline o immutabili e testati possono limitare l’impatto di una compromissione. Se un endpoint mostra beaconing sospetto, attività di shell o DLL sideloading, va isolato rapidamente preservando i log dell’endpoint, i dati di rete e, quando opportuno, la memoria per l’analisi forense.

In sintesi

La rilevanza di C2Looper sta nel passaggio da un backdoor HTTP relativamente lineare a un impianto più flessibile, capace di usare repository GitHub come infrastruttura operativa. Le sue funzioni di shell remota, ricognizione, download e aggiornamento lo rendono un possibile punto d’appoggio per intrusioni legate al ransomware. Le prove disponibili, però, richiedono prudenza e non consentono un’attribuzione definitiva.

La difesa più efficace combina procedure resistenti al ClickFix con la ricerca comportamentale di esecuzioni di comandi anomale, DLL sideloading tramite OneDrive, polling HTTP molto frequente e attività GitHub non giustificate.