I sistemi di controllo Cisco Catalyst SD-WAN compromessi sono diventati un punto di raccolta di chiavi di crittografia in attacchi che usano un malware personalizzato chiamato KeyDrift, secondo i risultati di Cisco Talos riportati da The Hacker News. Gli attaccanti hanno ottenuto l'accesso sfruttando CVE-2026-20127, un bypass dell'autenticazione corretto a febbraio.
Nella comunicazione del 28 ottobre, Talos ha descritto gli attacchi come storici, senza però fornire date degli incidenti. I risultati documentano un malware progettato per raccogliere e trasmettere presunto materiale di chiavi. Non dimostrano che le chiavi siano arrivate agli attaccanti né che il traffico di rete sia stato decifrato.
Raccolta delle chiavi all'interno del processo di controllo
KeyDrift inserisce il suo componente LittleFilch all'interno di vdaemon, il processo del Controller responsabile delle connessioni di controllo cifrate. Da lì, LittleFilch esamina i messaggi dopo la decifratura, selezionando indirizzi IP e un campo di 32 byte per un insieme predefinito di router di edge. Talos ritiene che tale campo contenga materiale di chiavi AES-256 distribuito tramite il Controller.
Il punto di raccolta corrisponde all'architettura tradizionale di scambio delle chiavi di Cisco. La documentazione tecnica di Cisco descrive router che generano una chiave AES per ogni punto di trasporto, o TLOC, e la inviano nei pacchetti di route dell'Overlay Management Protocol. Il Controller ridistribuisce tali informazioni nei messaggi di annuncio di raggiungibilità, in modo che i router possano stabilire percorsi dati cifrati. Le chiavi AES si rigenerano ogni 24 ore per impostazione predefinita, e le policy di controllo possono limitare quali router ricevono le chiavi reciproche.
Questa architettura è diversa dall'opzione a chiavi a coppie di Cisco. Con le chiavi a coppie, il Controller distribuisce valori pubblici Diffie-Hellman, mentre i router di edge derivano le proprie chiavi IPsec tramite ECDH e una curva P-384. Il comportamento riportato di LittleFilch riguarda il materiale di chiavi trasportato dallo scambio tradizionale; non dimostra la raccolta di chiavi derivate con il metodo a coppie.
LittleFilch protegge i record raccolti con la cifratura RSA prima di salvarli in /var/tmp/vdaemon.bin. Una funzione separata invia i record via UDP a una destinazione indicata in /var/tmp/vdaemon.conf. Il malware elimina quel file di configurazione dopo averlo letto, e non è stato possibile recuperarlo. Se la trasmissione sia avvenuta resta da chiarire.
Come operano i malware
L'analisi di Talos, riportata da The Hacker News, descrive le modifiche agli script di avvio dei servizi come principale meccanismo di avvio di KeyDrift. Una variante modifica lo script di esecuzione in etc/sv/sshd/ in modo che conf_sshd venga eseguito prima del vero server SSH. Quel loader scrive gli ID dei processi vdaemon in /tmp/system-vdaemon. Un injector chiamato rsshd inserisce quindi PolyFlame, il modulo principale di KeyDrift, in quei processi.
PolyFlame opera in memoria. La sua backdoor, simile a TinyShell, supporta esecuzione di comandi e lettura e scrittura di file, mentre una modalità relay inoltra i comandi tra un server di comando e altre macchine. I comandi possono arrivare all'interno del traffico di controllo SD-WAN. Nei campioni analizzati non è comparso alcun indirizzo di server codificato nel programma.
Un impianto Validator segue una strada diversa. Un servizio fasullo in /etc/sv/aaamgr/ avvia il loader compresso aaamgrd, che decifra ed esegue PolyFlame. La distinzione è rilevante per il rilevamento: il vero componente aaamgr di Cisco è un pacchetto Python e normalmente non opera come servizio compilato. Secondo quanto riportato, i nomi dei moduli sono libdssl.so per PolyFlame e libcommon.so per LittleFilch.
Talos ha inoltre osservato comandi che trasferiscono data e ora di modifica e permessi dei file esistenti a file creati dagli attaccanti. È un segno di timestomping, volto ad alterarne la storia apparente.
Il difetto di accesso e le correzioni disponibili
L'avviso di Cisco identifica come vulnerabilità di fondo un'autenticazione difettosa tra peer. Richieste costruite ad arte da un attaccante remoto non autenticato possono portare a privilegi amministrativi. Su un Controller, l'account interno che ne risulta è altamente privilegiato ma non è root: consente l'accesso NETCONF e modifiche alla configurazione della fabric SD-WAN.
I prodotti interessati sono Catalyst SD-WAN Controller, Manager e Validator, in precedenza noti come vSmart, vManage e vBond, indipendentemente dalla configurazione. L'ambito di distribuzione comprende le installazioni on-premises e Cisco Hosted SD-WAN Cloud, inclusi gli ambienti Cisco Managed e FedRAMP. Cisco riconosce uno sfruttamento limitato e raccomanda l'aggiornamento, perché nessuna soluzione alternativa risolve la falla.
Le correzioni specifiche per ciascuna release sono:
| Linea di release Catalyst SD-WAN | Prima release corretta o migrazione richiesta |
|---|---|
| Precedenti alla 20.9 | Migrare a una release corretta |
| 20.9 | 20.9.8.2 |
| 20.11 | 20.12.6.1 |
| 20.12 | 20.12.5.3 o 20.12.6.1 |
| 20.13 | 20.15.4.2 |
| 20.14 | 20.15.4.2 |
| 20.15 | 20.15.4.2 |
| 20.16 | 20.18.2.1 |
| 20.18 | 20.18.2.1 |
Cisco segnala come giunte a fine manutenzione software le release precedenti alla 20.9 e le linee 20.11, 20.13, 20.14 e 20.16. Invita i clienti a scegliere una release supportata.
Ai clienti on-premises in attesa di un aggiornamento, Cisco raccomanda di limitare le porte 22 e 830 ai controller noti e agli altri sistemi specifici che necessitano di accesso. Questa mitigazione ha funzionato in un ambiente di test. I clienti devono valutarne l'efficacia e i possibili effetti sulla funzionalità o sulle prestazioni della rete nelle proprie implementazioni. Cisco afferma che questi limiti di accesso esistono già negli ambienti hosted elencati. Tale affermazione attesta la presenza di restrizioni, non lo stato di applicazione delle patch su ogni istanza hosted.
Il rilevamento deve riguardare anche la compromissione già avvenuta
Cisco consiglia di controllare /var/log/auth.log alla ricerca di voci Accepted publickey for vmanage-admin associate a indirizzi IP sconosciuti o non autorizzati. Successivamente, i clienti devono confrontare tali indirizzi con i System IP configurati in Manager. Cisco richiede inoltre la convalida manuale degli eventi di peering delle connessioni di controllo, in particolare dei peer vmanage, usando ruoli previsti dei dispositivi, indirizzi, attività di manutenzione e registrazioni di autenticazione.
Prima di aprire una richiesta al Technical Assistance Center, i clienti dovrebbero eseguire request admin-tech su ogni componente di controllo. The Hacker News riferisce inoltre che le indicazioni di rimedio di Cisco raccomandano di ripetere la scansione di quei file tramite Check Bug Applicability nella pagina Bug Search Tool per CSCws52722.
Per il rilevamento di rete, l'aggiornamento di Talos del 28 ottobre ha introdotto le regole Snort 2 da 67387 a 67416 e le regole Snort 3 da 7:44 a 7:73 per le connessioni in ingresso di comando e controllo di KeyDrift. Le regole Snort 2 sono disattivate per impostazione predefinita e richiedono l'attivazione da parte degli utenti del set di regole Snort Subscriber a pagamento. L'aggiornamento non specifica uno stato predefinito per le regole Snort 3. Le regole 65938 e 65958 coprono lo sfruttamento della stessa CVE-2026-20127.
Talos raccomanda di applicare le correzioni, seguire le linee guida di hardening di Cisco e avviare la risposta agli incidenti quando compaiono segnali di compromissione successiva. La limitazione delle porte non rimuove il malware già installato. Come riportato da The Hacker News, citando la guida alla risoluzione di Cisco di febbraio, uno sfruttamento già avvenuto prima dell'aggiornamento potrebbe persistere anche dopo.
Per le agenzie del Federal Civilian Executive Branch, la direttiva ED 26-03 di CISA, emessa il 25 febbraio e aggiornata l'11 marzo, impone la segnalazione immediata quando si individua una compromissione dell'account root. Le agenzie devono ricostruire il piano di gestione del controllo con istanze nuove di Manager, Controller e Validator, ricavate da immagini OVA o qcow2 con patch, e migrare a esse i dispositivi di edge.
La sovrapposizione infrastrutturale limita l'attribuzione
Talos attribuisce l'attività KeyDrift a UAT-11473, un operatore che prende di mira servizi satellitari e spaziali, tecnologie per la difesa e l'aerospazio e la ricerca sulle politiche. Secondo The Hacker News, Talos valuta con alta confidenza che la sua infrastruttura si sovrapponga in misura sostanziale a Silent Train, il nome dato da Lumen Black Lotus Labs a una rete di dispositivi compromessi per piccoli uffici, uso domestico, IoT e aziende.
Lumen afferma che Volt Typhoon ha usato quella rete per occultare attività. CISA, NSA e FBI hanno identificato Volt Typhoon come gruppo sponsorizzato dallo Stato cinese nel 2024. Il legame infrastrutturale non equivale a un'identificazione di UAT-11473 come Volt Typhoon da parte di Talos. Talos, inoltre, non ha spiegato il suo rapporto con UAT-8616, il cluster di sfruttamento descritto a febbraio come risalente almeno al 2023.
Separatamente, The Hacker News riferisce che Lumen ha dichiarato il 28 ottobre che Volt Typhoon ha sfruttato CVE-2026-20127 entro la fine del 2025 e ha continuato dopo la divulgazione di febbraio. Lumen non ha attribuito KeyDrift a tale attività.
