Xen Orchestra sotto attacco, AhsayCBS compromesso: hacker puntano a server e backup

🛡️ Executive Summary

• Xen Orchestra è sotto attacco attraverso un bypass critico dell’autenticazione. La vulnerabilità VSA-2026-062 permette di ottenere privilegi amministrativi e arrivare al controllo root degli host XCP-ng.
• AhsayCBS viene compromesso attraverso due vulnerabilità già corrette. Huntress scopre cinque famiglie di web shell, due miner XMRig e una backdoor Python progettata per sfuggire alle sandbox.
• Gli aggressori puntano alle infrastrutture di gestione e alle credenziali dei backup. Xen Orchestra richiede l’aggiornamento immediato; i server Ahsay compromessi necessitano di verifiche forensi e ripristino da sistemi affidabili.

Gli hacker stanno colpendo due componenti fondamentali delle infrastrutture aziendali: i sistemi di virtualizzazione e le piattaforme di backup. Il 10 novembre 2026 Vates conferma lo sfruttamento attivo di una vulnerabilità critica in Xen Orchestra, capace di aggirare l’autenticazione e consentire il controllo degli host XCP-ng. Contemporaneamente Huntress ricostruisce una compromissione di AhsayCBS molto più articolata rispetto alle prime campagne di cryptomining osservate a ottobre. Gli attaccanti hanno distribuito web shell, strumenti di accesso remoto e una backdoor Python che riconosce il computer infettato prima di eseguire il proprio codice, rendendo più difficile l’analisi del malware. In entrambi i casi il bersaglio non è un semplice endpoint, ma un’infrastruttura che concentra privilegi, autorizzazioni e accessi ad altri sistemi. Compromettere il software che amministra macchine virtuali o backup significa potenzialmente ottenere il controllo delle risorse che un’azienda utilizza per funzionare e riprendersi dagli incidenti.

Xen Orchestra, un cookie manipolato permette di entrare senza password

La vulnerabilità VSA-2026-062, classificata critica da Vates, interessa Xen Orchestra e Xen Orchestra Appliance (XOA), piattaforme utilizzate per amministrare macchine virtuali, host e pool XCP-ng. Secondo il bollettino ufficiale di sicurezza, il problema nasce dall’elaborazione dei cookie utilizzati per l’autenticazione nelle API REST. Una richiesta costruita per rappresentare un oggetto JSON vuoto può indurre il sistema a recuperare un token esistente senza applicare il controllo previsto. Se il token appartiene a un amministratore, l’attaccante ottiene i relativi privilegi senza conoscere le credenziali. Il bypass può trasformarsi in esecuzione arbitraria di codice sui pool gestiti e nel controllo degli host XCP-ng con privilegi root. La vulnerabilità, individuata da Filip Magic e Christoffer Olsen di TDC NET Security, non dispone ancora di un identificativo CVE o di un punteggio CVSS ufficiale.

Il problema è già sfruttato in attacchi reali. Vates ha identificato un’infrastruttura ostile associata all’indirizzo 91.211.251.112 e a un servizio nascosto Tor. Gli aggressori possono sfruttare l’accesso amministrativo per intervenire sulle macchine virtuali, creare nuovi punti di accesso e modificare configurazioni dell’ambiente. Il rischio interessa soprattutto le console raggiungibili attraverso reti non sufficientemente isolate. L’aspetto più insidioso è che l’accesso ottenuto tramite il cookie malevolo non lascia necessariamente tracce nei normali log di autenticazione: l’assenza di eventi sospetti non basta quindi a dimostrare che il sistema sia rimasto integro.

Vates distribuisce le patch e pubblica gli indicatori di compromissione

Vates ha corretto la vulnerabilità con Xen Orchestra 6.9.1 nel canale Stable e 6.10.0 nel canale Latest, che integrano rispettivamente xo-server 5.211.2 e 5.213.1. L’aggiornamento è urgente, ma il produttore raccomanda anche di isolare le console dalle reti pubbliche, limitando l’accesso alle sole infrastrutture amministrative autorizzate. Tra gli indicatori pubblicati figurano una macchina virtuale denominata pivot2, configurazioni con parametro hvm_serial: file e file anomali come /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2 e /.ustar5. Le richieste HTTP con il cookie responsabile del bypass possono essere individuate attraverso il monitoraggio del traffico, mentre la verifica dei soli registri applicativi rischia di non intercettare l’accesso fraudolento.

Se emerge una compromissione, aggiornare Xen Orchestra non è sufficiente. Occorre verificare le macchine virtuali, controllare eventuali attività persistenti e sostituire password, token e credenziali utilizzati dall’infrastruttura, comprese quelle associate ai backup e agli account privilegiati. Il caso si inserisce nella superficie già evidenziata dagli attacchi contro gli hypervisor VMware ESXi e dalle tecniche di evasione delle macchine virtuali: quando viene compromesso il livello che gestisce la virtualizzazione, la sicurezza dei singoli sistemi ospitati può diventare secondaria rispetto al controllo conquistato sull’infrastruttura sottostante.

AhsayCBS, Huntress scopre cinque web shell e una backdoor Python

Il secondo incidente interessa AhsayCBS, piattaforma utilizzata da aziende e Managed Service Provider per amministrare backup e ripristini. Le vulnerabilità CVE-2026-105133 e CVE-2026-105134, già sfruttate durante ottobre, consentono di aggirare l’autenticazione ed eseguire comandi sui server compromessi. Come documentato nella precedente analisi sugli attacchi AhsayCBS e sulle patch incomplete, gli aggressori avevano inizialmente utilizzato le falle per installare web shell e miner XMRig. La nuova ricostruzione di Huntress rivela però cinque famiglie differenti di web shell JSP, comprese nsmind.jsp, capace di eseguire comandi e trasferire file, e AhsayCBS.jsp, che nasconde payload cifrati nei dati delle immagini PNG per caricarli successivamente in memoria. Accanto al miner camuffato da Microsoft Edge compare kvm-agent.exe, un secondo XMRig mantenuto attivo attraverso un’attività pianificata con privilegi SYSTEM.

La scoperta più significativa riguarda main.py, una backdoor Python progettata per funzionare esclusivamente sul computer scelto dall’attaccante. Il malware calcola l’hash SHA-256 del MachineGuid di Windows e cerca un file di controllo con lo stesso identificativo. Se la verifica fallisce, l’impianto non procede normalmente, ostacolando l’esecuzione negli ambienti di analisi. In caso contrario carica una DLL direttamente in memoria e comunica con il server di comando e controllo creepexplosiondarknight[.]com. Gli aggressori hanno inoltre predisposto strumenti di tunneling come GOST e Chisel, applicazioni legittime quali AnyDesk, Atera e Splashtop e modifiche alle esclusioni di Microsoft Defender. Il quadro descritto dalla ricerca Huntress sugli attacchi AhsayCBS supera quindi il semplice sfruttamento opportunistico per minare criptovalute.

Il vero obiettivo potrebbe essere il furto delle credenziali dei backup

L’elemento che cambia la lettura dell’incidente è stato osservato su un server Veeam collegato allo stesso ambiente compromesso. Huntress ha rilevato un comando compatibile con il modulo di furto delle credenziali Veeam di NetExec, attraverso uno script PowerShell eseguito apparentemente da remoto via WMI. Il codice interrogava il database PostgreSQL VeeamBackup e utilizzava DPAPI per tentare di decifrare le credenziali archiviate. I ricercatori non possono stabilire quante informazioni siano state effettivamente recuperate, ma l’attività suggerisce un interesse specifico per i segreti utilizzati dai sistemi di backup. Non è un dettaglio marginale: queste piattaforme custodiscono spesso credenziali di hypervisor, repository, account di dominio e infrastrutture di ripristino. Il rischio era già emerso nelle vulnerabilità Veeam capaci di esporre credenziali e accessi amministrativi.

Le vulnerabilità Ahsay risultano corrette attraverso gli hotfix 10.3.4.45 e 9.15.2.70, ma Huntress avverte che un server già compromesso potrebbe conservare web shell, servizi malevoli e accessi persistenti anche dopo l’aggiornamento. In presenza di indicatori attendibili viene raccomandato il ripristino completo da un’immagine affidabile, accompagnato dalla rotazione delle credenziali. Xen Orchestra e AhsayCBS mostrano così due percorsi differenti verso lo stesso risultato: conquistare il controllo delle infrastrutture che governano le risorse aziendali. Nel primo caso l’attaccante aggira l’autenticazione della console di virtualizzazione; nel secondo sfrutta il server di backup per mantenere accessi nascosti e raggiungere altre credenziali. La difesa deve partire dalle patch, ma non può terminare con esse: quando il sistema di amministrazione è stato violato, bisogna verificare tutto ciò che quel sistema aveva il potere di controllare.