Il RAT ChainScript trasforma gli smart contract Polygon in una directory C2 riconfigurabile

Il RAT ChainScript sfrutta falsi installer ClickFix, Node.js e PowerShell per colpire Windows e usare smart contract Polygon come directory C2.

Il RAT ChainScript trasforma gli smart contract Polygon in una directory C2 riconfigurabile
Malware

Immagine illustrativa generata con AI

Falsi installer software avviano la catena d’attacco su Windows

Gli attori delle minacce stanno sfruttando tecniche di social engineering in stile ClickFix per installare un trojan di accesso remoto per Windows, finora non documentato, chiamato ChainScript. Il malware offre agli operatori accesso interattivo ai sistemi compromessi e utilizza la blockchain Polygon per individuare un’infrastruttura di comando e controllo sostituibile.

Il Blackpoint Adversary Pursuit Group ha identificato quattro nomi delle build di ChainScript:

  • ComponentTask33
  • UpdateDigital
  • HostShared
  • OrchidViolet66

Le build si spacciano per software associati a Spotify, Zoom Workplace e Microsoft Teams. Un installer a tema Spotify osservato dagli analisti si chiama ComponentTask33-4d14e6ac.msi.

I programmi legittimi vengono impersonati; in relazione a questa campagna non è stata identificata alcuna vulnerabilità in Spotify, Zoom Workplace, Microsoft Teams, Node.js o Windows. Di conseguenza, non esistono intervalli di versioni interessate, identificativi CVE, punteggi CVSS o patch del fornitore.

L’intrusione si basa invece sulla persuasione della vittima, che viene indotta a scaricare ed eseguire un pacchetto MSI tramite msiexec.exe. È il modello ClickFix ormai noto: una pagina web presenta un problema inventato o un requisito di installazione e istruisce l’utente a compiere un’azione che esegue codice fornito dall’attaccante.

I risultati specifici su ChainScript, inclusa la catena di installazione e il resolver basato su Polygon, sono attribuiti al report tecnico di Blackpoint APG.

Node.js, PowerShell e VBScript nascondono l’impianto

Dopo l’esecuzione, l’MSI dannoso installa il runtime Node.js e colloca diversi componenti in directory dall’aspetto legittimo riconducibili a Microsoft, all’interno di %LOCALAPPDATA%. Tra questi file figurano l’agente JavaScript di ChainScript, i materiali di configurazione e alcuni binari ausiliari.

La catena di distribuzione utilizza quindi fasi nascoste basate su PowerShell e VBScript. VBScript funge da launcher principale per l’agente JavaScript, che viene eseguito tramite l’ambiente Node.js installato.

Questo approccio offre all’operazione diverse possibilità di confondersi con la normale attività del sistema. I pacchetti MSI sono meccanismi comuni per la distribuzione aziendale, PowerShell è uno strumento standard di amministrazione e Node.js potrebbe essere già presente sulle workstation di sviluppo. Il comportamento sospetto emerge dalla sequenza e dalla posizione dei componenti, più che da un singolo eseguibile.

Una volta avviato, ChainScript stabilisce la persistenza a livello utente tramite un’attività pianificata. Mantiene inoltre una chiave Run del Registro di sistema come meccanismo di riserva, offrendo un ulteriore metodo di esecuzione quando l’utente accede al sistema.

Le informazioni disponibili non rivelano il nome dell’attività pianificata, il nome del valore del Registro, i nomi dei file installati, gli hash dei file né i percorsi esatti all’interno di %LOCALAPPDATA%. I difensori non possono quindi fare affidamento su un insieme completo di indicatori statici host-based.

Una sequenza comportamentale utile da analizzare è la seguente:

  1. Un MSI scaricato di recente viene avviato tramite msiexec.exe.
  2. L’installer scrive un runtime Node.js e file JavaScript all’interno del profilo utente.
  3. PowerShell o VBScript avvia o utilizza quei file.
  4. Poco dopo compare un’attività pianificata a livello utente o una chiave Run.
  5. Node.js stabilisce una connessione WebSocket in uscita.

Questa catena è molto più caratteristica dei singoli componenti che la compongono.

Polygon funge da directory per server C2 sostituibili

La caratteristica distintiva di ChainScript è il suo processo di individuazione del C2 in stile EtherHiding. L’impianto non si affida esclusivamente a un indirizzo server incorporato permanentemente nel codice. Interroga invece uno smart contract Polygon per sapere dove si trova il server WebSocket di comando e controllo attivo.

Il processo di connessione si articola in quattro fasi principali:

  1. ChainScript contatta il contratto Polygon pertinente.
  2. I dati controllati dal contratto identificano l’infrastruttura WebSocket corrente.
  3. L’impianto si connette a quel server.
  4. Il server fornisce comandi e ulteriori attività da eseguire.

Un operatore può modificare i dati di risoluzione per indirizzare i sistemi infetti verso una nuova infrastruttura. Gli impianti già distribuiti possono quindi riconnettersi senza richiedere una nuova build del malware o un’ulteriore interazione con la vittima.

Questa separazione rende meno duraturi i tradizionali meccanismi di blocco. Mettere offline o negare l’accesso a un singolo host WebSocket può interrompere temporaneamente le operazioni, ma l’operatore può reindirizzare il malware finché mantiene il controllo del processo di risoluzione basato sul contratto.

Riduce inoltre il valore dell’estrazione di un singolo indirizzo di rete da un campione. Il rilevamento deve tenere conto della consultazione dello smart contract, della successiva sessione WebSocket e dei processi responsabili di entrambe le attività.

Non sono stati resi disponibili indirizzi di contratti Polygon, hostname WebSocket, indirizzi IP o indirizzi di wallet di criptovalute. ChainScript non è inoltre associato a una vulnerabilità divulgata né a una voce del catalogo CISA Known Exploited Vulnerabilities.

L’accesso remoto include screenshot, payload e wallet

Dopo aver raggiunto il proprio server, ChainScript può aprire sessioni interattive di Prompt dei comandi e PowerShell. L’operatore ottiene così il controllo diretto del sistema, anziché limitarsi a un insieme prestabilito di funzioni automatizzate per il furto di dati.

I comandi supportati includono:

  • Lettura, scrittura e manipolazione dei file
  • Acquisizione di screenshot
  • Installazione di payload aggiuntivi
  • Esecuzione di JavaScript fornito da remoto
  • Aggiornamento dell’impianto
  • Rimozione dei meccanismi di persistenza
  • Individuazione dei wallet di criptovalute nelle applicazioni desktop
  • Individuazione delle estensioni del browser relative ai wallet di criptovalute

Queste funzionalità possono avere diverse conseguenze per le vittime. Gli operatori possono esaminare i dati locali, monitorare ciò che viene visualizzato sullo schermo, distribuire altro malware e utilizzare le shell native per andare oltre le funzioni integrate di ChainScript.

L’individuazione dei wallet è particolarmente significativa perché consente di identificare obiettivi di alto valore prima di procedere con il furto. Le informazioni disponibili non dimostrano che ogni sistema infetto abbia subito un furto di criptovalute e non forniscono né il numero di vittime né la distribuzione geografica di ChainScript.

La capacità di ChainScript di rimuovere la persistenza complica inoltre le attività di analisi. Un operatore potrebbe eliminare determinati artefatti lasciando intatti altri payload. Trovare ed eliminare l’MSI originale non dimostrerebbe quindi che il sistema sia sicuro.

Gli operatori ClickFix filtrano anche i visitatori macOS

L’attività su Windows rientra in un quadro più ampio di operazioni ClickFix che combinano comandi eseguiti dall’utente con un’infrastruttura progettata per ostacolare l’analisi automatizzata.

In un avviso pubblicato separatamente il 5 agosto 2026, Microsoft ha documentato una campagna ClickFix per macOS che distribuiva MacSync e Atomic Stealer (AMOS). Microsoft non ha documentato in modo indipendente ChainScript né il suo resolver Polygon, ma i suoi risultati mostrano come i siti utilizzati per distribuire ClickFix possano rivelare selettivamente i contenuti dannosi.

Durante il monitoraggio, Microsoft ha identificato più di 250 domini front-end. Alcuni utilizzavano nomi composti da termini del dizionario contenenti file, mentre altri omettevano quel termine. Tra gli esempi figuravano filecopperbasket, applefilevault e cloudsendhub.

L’infrastruttura si è evoluta: dalle istruzioni dannose inserite direttamente nell’HTML della pagina è passata alla distribuzione di un profiler JavaScript leggero. Il codice raccoglieva proprietà da navigator, screen, window, document, location e console, integrandole con segnali hardware WebGL e controlli relativi a fuso orario, stato degli iframe e supporto al touch.

I visitatori che sembravano utilizzare un Mac reale potevano ricevere il falso invito a scaricare il malware. Crawler, sandbox e sistemi non conformi ai requisiti potevano invece visualizzare una pagina vuota o un’esca priva di collegamenti con l’attacco.

Una delle pagine che soddisfacevano i requisiti, disponibile all’indirizzo apricotfilepoint[.]com, mostrava un falso badge “Verified Publisher” e proponeva un comando curl offuscato. Una richiesta diversa allo stesso dominio restituiva una pagina fasulla di Urban VPN Proxy.

Una singola risposta apparentemente innocua è quindi un indizio poco significativo. Testare un’infrastruttura sospetta utilizzando un solo scanner o un unico profilo del browser può non rilevare contenuti ClickFix distribuiti selettivamente.

I difensori devono privilegiare il comportamento rispetto agli indicatori statici

Le organizzazioni possono iniziare dal nome noto dell’installer, ComponentTask33-4d14e6ac.msi, senza però presumere che tutte le build di ChainScript lo utilizzino. Gli altri nomi di build segnalati — ComponentTask33, UpdateDigital, HostShared e OrchidViolet66 — offrono ulteriori elementi per le attività di threat hunting.

I team che gestiscono gli endpoint dovrebbero correlare le attività di msiexec.exe, PowerShell, VBScript e Node.js, soprattutto quando i file coinvolti risiedono all’interno di %LOCALAPPDATA%. I processi Node.js avviati da directory del profilo utente create di recente meritano particolare attenzione se aprono connessioni WebSocket o eseguono JavaScript non riconosciuto.

Altre priorità includono:

  • Esaminare le attività pianificate a livello utente e le chiavi Run del Registro create di recente
  • Analizzare il traffico WebSocket in uscita anomalo
  • Correlare l’accesso agli smart contract Polygon con le attività di Node.js o degli script
  • Monitorare l’accesso ai profili delle estensioni del browser e ai dati dei wallet desktop
  • Cercare acquisizioni di screenshot ed esecuzione di JavaScript fornito da remoto
  • Conservare la telemetria relativa a PowerShell, creazione dei processi, Utilità di pianificazione e Registro di sistema

Gli utenti devono essere istruiti a non incollare comandi in PowerShell, nel Prompt dei comandi o nel Terminale macOS solo perché un sito sostiene che siano necessari per la verifica, l’installazione o la risoluzione di un problema.

Non esiste uno strumento dedicato per la rimozione di ChainScript. Un endpoint sospetto dovrebbe essere isolato e analizzato lungo l’intera catena di esecuzione, verificando le voci di persistenza e i payload secondari, non soltanto l’MSI iniziale. Il semplice blocco degli indirizzi C2 statici difficilmente sarà sufficiente, perché il resolver basato su Polygon è stato progettato per mantenere operativo l’impianto anche dopo la disattivazione dei singoli server backend.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Argomenti correlatiChainScriptRAT WindowsClickFixsmart contract PolygonC2 riconfigurabileNode.jsPowerShell
Torna alla home