AOMEI Backupper compromesso: il malware arrivava dagli update ufficiali

Un aggiornamento software può trasformarsi in un attacco informatico anche quando il programma installato sul PC non presenta vulnerabilità note e i file ufficiali del produttore risultano perfettamente legittimi. È quanto emerge da un’indagine pubblicata da Google Threat Intelligence Group (GTIG) e Mandiant, che hanno ricostruito una sofisticata campagna di attacco alla supply chain software ai danni dell’infrastruttura di aggiornamento di AOMEI Technology, sviluppatore di applicazioni molto diffuse per il backup, la clonazione dei dischi e l’accesso remoto.

Tra aprile e luglio 2026, un gruppo di criminali informatici identificato come UNC7017 ha ripetutamente modificato alcuni file di configurazione distribuiti dai server AOMEI, lasciando attive le alterazioni per appena 5-10 minuti. Terminata ogni operazione, gli aggressori ripristinavano i file originali; chi controllava i server trovava quindi configurazioni autentiche, senza tracce immediatamente evidenti dell’attacco.

AOMEI sotto attacco: il problema non era nel software installato

Avrete certamente sentito parlare o direttamente utilizzato programmi come AOMEI Backupper, che consente di effettuare copie di sicurezza, clonare dischi e ripristinare sistemi Windows oppure AnyViewer, che offre invece funzionalità di desktop remoto e assistenza a distanza.

Entrambi i prodotti utilizzano componenti che comunicano periodicamente con l’infrastruttura del produttore per recuperare informazioni sugli aggiornamenti e contenuti promozionali. Nel flusso analizzato dai ricercatori compaiono due processi: Backupper.exe, coinvolto nel recupero dei pacchetti, e ABNotify.exe, responsabile della gestione delle notifiche.

Il meccanismo utilizzato da AOEMI poggia sull’uso del file down_html.ini, che al suo interno contiene l’indirizzo del pacchetto di aggiornamento, e di Notifycfg.ini le cui direttive regolano il comportamento delle notifiche e possono indicare all’applicazione quali contenuti visualizzare e quali programmi eseguire all’interno delle directory locali.

Un file decide quali contenuti scaricare, l’altro può provocarne l’esecuzione: se un aggressore riesce ad alterare entrambe le configurazioni, può sfruttare la funzione come un sistema di distribuzione di malware. Secondo l’analisi indipendente di ManageEngine Threat Analysis Lab (METAL), il meccanismo non richiedeva lo sfruttamento di una vulnerabilità software classificata con un identificativo CVE.

Una modifica di appena 5 minuti per infettare i computer

Google e Mandiant non hanno stabilito pubblicamente come gli aggressori abbiano ottenuto l’accesso ai server AOMEI. Non sappiamo, quindi, se abbiano sfruttato credenziali sottratte, una vulnerabilità dell’infrastruttura o un altro metodo per modificare i file. Le indagini hanno però ricostruito con precisione ciò che accadeva dopo la compromissione.

I ricercatori hanno documentato tre intervalli temporali durante i quali i server distribuivano configurazioni alterate. Durante tali finestre, i computer che interrogavano i server AOMEI potevano ricevere istruzioni malevole; tutti gli altri continuavano a ottenere le configurazioni regolari. Non era quindi necessario colpire ogni installazione del prodotto: bastava intercettare alcuni client durante i rispettivi controlli periodici.

La tecnica, definita dai ricercatori ephemeral supply chain tampering, sfrutta soprattutto un limite delle attività di verifica tradizionali. Un controllo eseguito una volta al giorno, oppure dopo la segnalazione di un problema, può non rilevare alcuna anomalia perché il materiale compromesso non è più presente.

Il programma eseguito attraverso il falso aggiornamento era CROSSROAD, un downloader progettato per recuperare ulteriori componenti malevoli. Dopo alcuni controlli sul computer, il downloader scaricava e installava SHINYROAD, una backdoor che permetteva agli aggressori di mantenere l’accesso al sistema e impartire comandi a distanza.

Per rendere persistente l’infezione, il malware creava un’attività pianificata di Windows denominata RadminComponentRuntime, che riattivava i componenti installati ogni 3 ore.

Come Google e ManageEngine hanno scoperto l’attacco

La scoperta iniziale si deve ai ricercatori di METAL che alla fine di maggio 2026 avevano rilevato comportamenti anomali su alcuni computer protetti dalle proprie soluzioni EDR (Endpoint Detection and Response): i sistemi mostravano un processo AOMEI impegnato ad avviare programmi sospetti e installare componenti di amministrazione remota.

Il problema era che, quando gli analisti provavano a controllare i file scaricati dai server AOMEI, trovavano soltanto contenuti legittimi. Come spiegato in precedenza, gli aggressori avevano già ripristinato le configurazioni originali.

ManageEngine ha perciò approfondito e avviato controlli ripetuti sui file di aggiornamento; la collaborazione con Google Threat Intelligence Group e Mandiant ha permesso di collegare gli episodi, analizzare i malware e identificare le brevi finestre temporali durante le quali i server distribuiscono istruzioni dannose.

La risposta di AOMEI e il rischio per chi utilizza i programmi

Il 17 luglio 2026 Mandiant ha informato ufficialmente AOMEI della compromissione dell’infrastruttura di aggiornamento, trasmettendo le informazioni tecniche raccolte durante le indagini.

Il produttore ha risposto il 29 luglio 2026, comunicando di aver adottato misure correttive per proteggere i server di distribuzione. Nel rapporto di Google, tuttavia, non compare una descrizione dettagliata degli interventi, né viene chiarito quale debolezza avesse consentito agli aggressori di modificare inizialmente le configurazioni.

La correzione applicata lato server, inoltre, non elimina automaticamente eventuali infezioni precedenti. Un computer che avesse scaricato il falso aggiornamento durante una delle brevi finestre di attacco potrebbe ancora ospitare i componenti malevoli e le attività pianificate utilizzate per mantenerli attivi.

Per questo Google raccomanda alle organizzazioni che utilizzano software AOMEI di esaminare retrospettivamente gli eventi registrati tra aprile e luglio 2026. Tra gli elementi da verificare figurano le attività pianificate RadminComponentRuntime e NitroRuntime, la presenza di librerie sospette nelle cartelle locali di Radmin e Nitro Pro e le connessioni verso i domini riportati nell’analisi (Network Indicators).

L’uso di HTTPS e di un checksum non garantiscono, da soli, l’autenticità di un aggiornamento se un aggressore riesce a modificare le istruzioni che il client riceve dal server.