Gli aggressori hanno modificato per pochi minuti i file serviti dai server di aggiornamento di AOMEI Backupper, facendo scaricare e avviare un backdoor ai PC Windows che controllavano la disponibilità di update in quelle finestre. La campagna, ricostruita da Google Threat Intelligence Group, Mandiant e ManageEngine, sarebbe avvenuta tra maggio e luglio 2026.
AOMEI ha riferito di aver corretto i propri server, ma l’intervento non rimuove automaticamente l’impianto dai computer già compromessi. Le analisi invitano quindi le organizzazioni che usano il software a cercare tracce dell’attività sull’intero periodo indicato.
Come è stato aggirato il controllo degli aggiornamenti
Il punto centrale non è una vulnerabilità sfruttata sul PC, ma la modifica dei contenuti distribuiti dal normale canale di aggiornamento. Secondo ManageEngine, non era necessaria un’azione dell’utente oltre ad avere Backupper installato e in esecuzione.
Il programma consulta due file: down_html.ini, che indica il pacchetto da scaricare e il relativo checksum, e Notifycfg.ini, usato dal servizio delle notifiche per decidere cosa mostrare e avviare. Il problema è che questi file non vengono verificati crittograficamente; inoltre, il checksum è contenuto nello stesso file non firmato che identifica il download.
In pratica, chi ha alterato i file sul server ha potuto sostituire per breve tempo il pacchetto legittimo con uno dannoso. Il file di notifica induceva poi Backupper a eseguirlo con i privilegi del processo AOMEI che lo aveva avviato. Nei sistemi esaminati da ManageEngine, questo è bastato in alcuni casi a installare software nell’intero sistema, con un risultato che dipendeva però da come era configurato il servizio AOMEI.
Tre finestre di pochi minuti
Google Threat Intelligence Group e Mandiant hanno confermato tre momenti di manomissione: il 28 maggio 2026 dalle 05:40 alle 05:50 UTC, il 16 luglio dalle 08:33 alle 08:39 UTC e il 20 luglio dalle 10:35 alle 10:40 UTC. Le indagini ritengono possibile che ce ne siano stati altri.
Era colpito soltanto il computer che interrogava i server proprio in quei minuti. Prima o dopo, il software riceveva file autentici: una caratteristica che rende la campagna difficile da rilevare con controlli eseguiti in un singolo momento. GTIG descrive il bersaglio come opportunistico, cioè legato ai sistemi che effettuavano la verifica in quelle finestre.
Dalla propria telemetria, GTIG ha individuato organizzazioni interessate nei settori dei servizi IT, delle telecomunicazioni e dell’istruzione superiore in 11 Paesi, fra cui Stati Uniti, Spagna, Portogallo, India e Australia. Non è stato comunicato un totale delle vittime e il numero reale potrebbe essere più alto.
Il backdoor e il tentativo di sottrarre credenziali
Il downloader chiamato CROSSROAD estraeva file in una cartella locale di Radmin, creava un’attività pianificata con esecuzione ogni tre ore e poi si cancellava dal disco. Il pacchetto includeva una copia firmata di Radmin, software commerciale di amministrazione remota, ma ManageEngine non ha rilevato configurazioni o listener attivi per quel programma.
L’attività pianificata avviava invece Radmin affinché caricasse una DLL collocata accanto all’eseguibile. Questa DLL portava al malware SHINYROAD, capace di offrire una shell remota e di scaricare ulteriore codice. L’impianto contattava un solo indirizzo predefinito: bloccarlo può quindi interrompere il controllo remoto descritto dai ricercatori.
Il 20 luglio sarebbe stata aggiunta anche una tecnica che non richiedeva l’esecuzione di un programma: un pop-up invisibile di un pixel puntava a un file remoto via WebDAV. La sua visualizzazione può indurre Windows a inviare all’indirizzo dell’attaccante la risposta di autenticazione NetNTLMv2 dell’utente connesso, utilizzabile per tentativi di cracking offline o riuso. Di conseguenza, la risposta di autenticazione poteva essere esposta anche se il backdoor fosse stato bloccato.
Cosa resta da chiarire e quali tracce cercare
I ricercatori attribuiscono la campagna al gruppo tracciato come UNC7017, senza associarlo a un Paese o a un attore noto. Non è noto neppure come gli aggressori abbiano ottenuto la capacità di modificare i file sui server AOMEI.
Le rilevazioni descritte riguardano Backupper; GTIG segnala che anche lo strumento di desktop remoto AnyViewer usa un flusso di aggiornamento simile, ma non indica compromissioni di quel prodotto. Non vengono inoltre elencate le versioni di Backupper coinvolte: ManageEngine ha esaminato la versione 8.3.0.
Il controllo successivo sul sito del fornitore non basta a escludere un’infezione. I file venivano ripristinati dopo pochi minuti e il downloader riportava i contenuti locali a uno stato apparentemente autentico. Tra gli indicatori indicati nelle analisi figurano le attività pianificate RadminComponentRuntime e NitroRuntime, un file non firmato chiamato upgrade-now.exe e file collocati nella cartella locale di Radmin.
FAQ
AOMEI ha risolto il problema?
AOMEI ha comunicato a Mandiant il 29 luglio di aver adottato misure correttive per proteggere i server. ManageEngine ha però precisato che, alla pubblicazione della propria analisi, non aveva verificato in modo indipendente il contenimento della compromissione.
Un PC già colpito torna sicuro dopo la correzione dei server?
No. La correzione lato server non rimuove l’impianto da una macchina che ha già scaricato il pacchetto dannoso. Per questo le analisi suggeriscono di cercare gli indicatori sull’intervallo da aprile a luglio 2026.
La campagna ha coinvolto tutti gli utenti di AOMEI Backupper?
No. In base alla ricostruzione, erano esposti i sistemi che cercavano aggiornamenti durante una delle brevi finestre in cui i file sui server erano stati modificati. Non è stato pubblicato un numero complessivo di macchine coinvolte.
Considerazioni finali
Questo caso mostra quanto sia fragile un meccanismo di aggiornamento quando il pacchetto e il controllo della sua integrità dipendono da file non firmati forniti dallo stesso canale. Non serve sfruttare una falla sul computer se la catena di fiducia lato server permette di indicare un download diverso e di farlo avviare dal software legittimo.
L’elemento più rilevante è la durata ridottissima delle manomissioni: pochi minuti possono lasciare poche prove visibili e rendere fuorvianti i controlli effettuati in seguito. Per chi usa AOMEI Backupper, il punto decisivo resta quindi verificare gli indicatori sui sistemi e nei log del periodo interessato, non soltanto controllare che oggi il download del fornitore risulti pulito.