UNC7017 colpisce AOMEI: supply chain attiva per soli cinque minuti

🛡️ Executive Summary

• UNC7017 ha compromesso l’infrastruttura di aggiornamento AOMEI modificandola per finestre di appena 5-10 minuti e ripristinando subito dopo i file autentici.
• I sistemi che interrogavano i server durante quelle finestre ricevevano CROSSROAD e SHINYROAD, mentre controlli eseguiti pochi minuti prima o dopo trovavano un’infrastruttura perfettamente legittima.
• Google Threat Intelligence definisce il metodo una novità nella supply chain: l’attacco riduce drasticamente le possibilità di catturare configurazioni malevole durante audit e scansioni puntuali.

Un attacco alla supply chain che può essere già scomparso quando il team di sicurezza arriva a controllare il server. Google Threat Intelligence Group e Mandiant hanno ricostruito una campagna attribuita al cluster UNC7017 che tra aprile e luglio 2026 ha compromesso l’infrastruttura di aggiornamento di AOMEI Technology utilizzando una tecnica particolarmente difficile da rilevare: le configurazioni malevole rimanevano online soltanto per cinque-dieci minuti, dopodiché venivano sostituite nuovamente con quelle autentiche. Il risultato è una forma di compromissione temporanea nella quale due utenti dello stesso software possono interrogare lo stesso server a pochi minuti di distanza e ricevere risposte completamente differenti. Per Google è la prima supply chain compromise osservata con finestre operative tanto brevi.

UNC7017 modifica gli aggiornamenti AOMEI e poi rimette tutto a posto

La ricerca pubblicata da Google Threat Intelligence e Mandiant riguarda l’infrastruttura utilizzata da AOMEI Backupper, software per backup e disaster recovery, e AnyViewer, piattaforma di accesso remoto. I client interrogano periodicamente server AOMEI per verificare aggiornamenti e notifiche attraverso file di configurazione come down_html.ini e Notifycfg.ini. UNC7017 non ha avuto bisogno di modificare permanentemente il programma distribuito agli utenti: durante specifiche finestre temporali cambiava direttamente queste configurazioni sul server, indicando al client di scaricare un archivio ZIP controllato dagli attaccanti e forzandone successivamente l’esecuzione. Google ha documentato una finestra di 10 minuti il 28 maggio, sei minuti il 16 luglio e appena cinque minuti il 20 luglio. Alla fine di ciascuna operazione i file venivano riportati allo stato originale.

È una differenza sostanziale rispetto a compromissioni più tradizionali come quella della supply chain 3CX, nella quale client compromessi venivano distribuiti agli utenti. In quel modello rimane un artefatto malevolo stabile da analizzare. Nel caso AOMEI il server può apparire pulito durante l’audit semplicemente perché il controllo avviene nel momento sbagliato.

Leggi anche: Shai-Hulud compromette 80 pacchetti TanStack con un worm supply chain su npm

Basta interrogare il server nei cinque minuti sbagliati

Durante le finestre di compromissione UNC7017 modificava il file che indica al client versione, hash MD5 e posizione dell’aggiornamento. L’URL legittimo veniva sostituito con infrastrutture controllate dall’attaccante e la versione incrementata affinché il software considerasse disponibile un nuovo update. Parallelamente Notifycfg.ini veniva manipolato per costringere il processo di notifica a eseguire il payload scaricato. Il primo componente individuato da Mandiant è CROSSROAD, downloader utilizzato per verificare l’ambiente e preparare gli stadi successivi; da qui veniva distribuito SHINYROAD, framework backdoor modulare con persistenza attraverso attività pianificate e strumenti di amministrazione alterati.

La vittimologia osservata comprende organizzazioni dei settori IT, telecomunicazioni e università in Australia, Brasile, India, Pakistan, Portogallo, Singapore, Sudafrica, Spagna, Svizzera, Turchia e Stati Uniti. Google precisa però che l’elenco potrebbe essere incompleto: qualsiasi sistema che avesse interrogato l’infrastruttura AOMEI durante una finestra attiva poteva ricevere le istruzioni malevole, rendendo l’esposizione opportunistica e potenzialmente più ampia della telemetria disponibile.

Google Cloud Storage diventa parte della mimetizzazione

Anche l’infrastruttura di distribuzione è cambiata durante la campagna. Nelle prime fasi CROSSROAD veniva ospitato su Alibaba Cloud Object Storage; successivamente UNC7017 è passato a domini apparentemente collegati al vendor come storage-data.com, promotion.storage-data.com e aomei.storage-data.com. Il 20 luglio gli attaccanti hanno introdotto un passaggio ancora più efficace: il primo archivio malevolo veniva distribuito attraverso un bucket pubblico Google Cloud Storage. L’obiettivo non era compromettere Google Cloud, ma sfruttare la reputazione di un’infrastruttura legittima per superare filtri che bloccano domini appena registrati. È la stessa asimmetria che rende pericolosi gli attacchi alle dipendenze e alle piattaforme di sviluppo: il traffico malevolo entra all’interno di una relazione considerata affidabile. Le campagne Shai-Hulud contro npm hanno già mostrato quanto credenziali cloud e pipeline CI/CD diventino bersagli privilegiati quando viene compromesso un componente della supply chain.

UNC7017 prova a rubare anche gli hash NetNTLMv2

La finestra del 20 luglio mostra inoltre che la compromissione non serviva soltanto a distribuire malware. UNC7017 ha sostituito una normale notifica promozionale con una finestra invisibile da 1×1 pixel che puntava attraverso WebDAV verso un server controllato dall’attaccante. Il client Windows veniva così indotto a tentare automaticamente l’autenticazione verso la risorsa remota, con la possibilità di trasmettere hash NetNTLMv2 senza una vera interazione dell’utente.

Il metodo crea quindi due percorsi paralleli: da un lato la distribuzione di CROSSROAD e SHINYROAD attraverso il sistema di aggiornamento; dall’altro una forma di credential coercion che può produrre informazioni utili all’attaccante anche quando l’esecuzione diretta del payload viene bloccata. A questo si aggiungono tecniche anti-forensics: CROSSROAD ripristina localmente alcune configurazioni AOMEI, altera timestamp e dispone di una procedura di auto-cancellazione progettata per ridurre gli artefatti disponibili dopo l’esecuzione.

La scansione periodica non basta più a certificare una supply chain pulita

La vera innovazione della campagna è temporale. Un controllo automatico che scarica ogni ora il file di configurazione avrebbe avuto ottime probabilità di vedere soltanto versioni autentiche, pur in presenza di una compromissione ripetuta. Un audit eseguito dopo una segnalazione avrebbe potuto portare alla stessa conclusione sbagliata: server pulito, file corretti, hash coerenti. È il motivo per cui Google raccomanda di spostare parte della difesa dalla semplice integrità statica al comportamento del processo di update, osservando child process non firmati, redirect di rete inattesi, attività pianificate anomale e connessioni WebDAV o SMB verso indirizzi esterni. Il problema riguarda l’intero modello di fiducia nella distribuzione software. Le difese temporali introdotte da GitHub e PyPI contro gli attacchi supply chain cercano già di ridurre la possibilità che modifiche appena introdotte si propaghino immediatamente. UNC7017 mostra il problema inverso: l’attaccante può utilizzare proprio il tempo come tecnica di evasione, facendo comparire l’infrastruttura malevola soltanto quando serve.

Continua con:

390.000 credenziali WordPress sottratte attraverso una supply chain compromessa

SpotBugs, reviewdog e tj-actions colpiti in un attacco alla supply chain GitHub Actions

L’attacco che sparisce cambia anche il modo di fare incident response

Mandiant ha notificato AOMEI il 17 luglio e il vendor ha comunicato il 29 luglio di avere adottato misure correttive sulla propria infrastruttura. Per le organizzazioni potenzialmente esposte, però, mettere in sicurezza il server del produttore non elimina ciò che potrebbe essere già arrivato sugli endpoint. Google indica quindi la necessità di cercare attività pianificate come RadminComponentRuntime, file riconducibili a CROSSROAD e connessioni verso l’infrastruttura utilizzata da UNC7017. La lezione più importante va oltre AOMEI. Le supply chain compromise più note hanno insegnato a controllare build, firme, repository e dipendenze. UNC7017 aggiunge il tempo alla superficie di attacco. Se una configurazione malevola esiste per cinque minuti e viene immediatamente cancellata, dimostrare a posteriori che un’infrastruttura fosse compromessa diventa molto più difficile. Per i difensori significa conservare maggiore telemetria storica e osservare il comportamento degli updater; per gli attaccanti significa poter sfruttare per pochi minuti la fiducia costruita da un vendor e lasciare dietro di sé un server apparentemente identico a quello che esisteva prima dell’attacco.