Dieci anni dentro una rete air-gap: l'Operazione Highland di Velvet Ant

L'air-gap è il controllo a cui tutti ricorrono quando i dati sono troppo importanti per essere persi. Nessuna rotta verso Internet in entrata, nessuna in uscita, quindi nessun attaccante remoto: è il modello mentale che giustifica l'isolamento di una rete di infrastruttura critica. L'Operazione Highland è il caso che lo smonta. Secondo il report di Sygnia pubblicato il 13 giugno 2026, il gruppo cinese tracciato come Velvet Ant è rimasto dentro la rete isolata di infrastruttura critica di una grande organizzazione per circa dieci anni — gli artefatti forensi datano la prima attività al 2016 — osservando ogni login amministrativo e ogni comando digitato per quasi tutto il decennio. Lo ha fatto senza un solo exploit nuovo, senza rilasciare nulla che un antimalware avrebbe segnalato, e senza che sia mai esistita una connessione diretta verso la rete segregata — una campagna riportata da BleepingComputer lo stesso giorno della pubblicazione della ricerca.

Questo articolo parla di come un air-gap fallisce nella pratica, perché il fallimento è invisibile ai controlli host-based su cui la maggior parte delle reti isolate fa affidamento, e cosa resta davvero per rilevarlo. In breve: l'attaccante ha compromesso l'unica cosa di cui ogni host Linux si fida per default — lo stack di autenticazione stesso — e l'unico punto in cui la sua attività è diventata osservabile è stato il traffico di rete.

L'air-gap che non c'era

Un air-gap è un'affermazione sulla topologia: non esiste percorso tra la rete sensibile e il mondo esterno. Velvet Ant non ha smentito quell'affermazione trovando un cavo nascosto. Ha costruito un percorso logico sopra infrastruttura fidata che nessuno stava ispezionando.

Secondo l'analisi di Sygnia, il ponte funzionava così. Un server Nginx esposto su Internet era configurato per inoltrare richieste a un backend compromesso. Quel backend eseguiva un wrapper FastCGI (fcgiwrap) che lanciava un binario su misura piantato dall'attaccante, nominato per sembrare una banale utility uptime. Il binario apriva connessioni SSH verso bersagli interni alla rete isolata sulla base di parametri trasportati in una POST HTTP. La catena merita di essere detta chiaramente: una richiesta HTTP dall'aspetto normale colpiva un web server dall'aspetto normale, e tre hop dopo un comando veniva eseguito su una macchina che, sullo schema di rete, non aveva alcun modo di raggiungere Internet.

Auditor: "Mostrami la regola firewall che permette alla DMZ di parlare con il segmento OT." Ingegnere: "Non c'è. È il punto — sono in air-gap." Auditor: "Allora come ha fatto una POST al web server pubblico a eseguire bash su un controllore PLC?"

Questo scambio è l'intero fallimento. L'air-gap era reale al livello di routing e privo di significato al livello applicativo, perché l'attaccante ha trasformato infrastruttura fidata ed esposta in un relay. Nessuna regola è stata violata. Una regola è stata composta a partire da pezzi che nessuno guardava insieme.

Compromettere lo stack di autenticazione: nessun exploit da intercettare

Il motivo per cui tutto questo è durato un decennio è che Velvet Ant non ha attaccato le difese della rete — ha attaccato la sua fiducia. La persistenza viveva dentro i componenti che ogni host Linux usa per decidere chi può entrare e cosa può fare.

• Pluggable Authentication Modules (PAM). Sygnia ha identificato nove distinte varianti di pam_unix.so con backdoor, ciascuna compilata in un ambiente separato. Una classe accettava semplicemente una password backdoor hardcoded e la cancellava dalla memoria; un'altra accettava la password Pamauth@123456 e registrava ogni username e password reali in /usr/sbin/.ssh.log. Le stringhe RPATH nei binari hanno persino rivelato i percorsi di build degli sviluppatori, come /home/kevin/Desktop/Linux-PAM-{version}/libpam/.libs.
• OpenSSH. Binari ssh, sshd e scp modificati catturavano le credenziali in file cifrati in percorsi come /usr/share/man9/ph/.ph.man, registravano ogni comando con un keylogger, lo memorizzavano cifrato in directory con timestamp manomesso, ed esponevano un flag -d su misura che l'operatore poteva usare per sopprimere il proprio logging durante una sessione.
• Strumenti di tunneling travestiti da daemon. Una reverse shell GS-Netcat modificata stava in /usr/sbin/ come auditdb, mascherata da kernel thread [khubd] e in uscita verso la Global Socket Relay Network. Un proxy SOCKS5 Perl su misura girava travestito da smbd -D, abilitando il movimento laterale host per host.

La formulazione di Sygnia è la frase su cui ogni difensore dovrebbe fermarsi: "l'attaccante non aveva alcun exploit nuovo da intercettare; nessun binario chiaramente malevolo che cade in una directory monitorata." Un pam_unix.so con backdoor si comporta in modo perfettamente normale per gli utenti legittimi. Non genera alcuna voce di log anomala — è la cosa che scrive i log. Non c'è alcun CVE da patchare, nessuna firma da abbinare, nessun alert EDR da far scattare, perché il comportamento malevolo è indistinguibile dall'evento più ordinario del sistema: qualcuno che fa il login.

L'air-gap è un problema di detection, non un controllo di sicurezza

È questo lo spostamento concettuale che l'Operazione Highland impone. Un air-gap viene venduto come prevenzione. In realtà è una scommessa sul fatto che non avrai mai bisogno di rilevare nulla, perché nulla può entrare. Una volta persa quella scommessa — ed è stata persa qui tramite il relay su infrastruttura fidata, non per una rottura della topologia — la rete isolata è il peggior posto in cui essere ciechi, perché è esattamente dove le organizzazioni risparmiano sul monitoraggio nella convinzione che sia irraggiungibile.

Velvet Ant ha una storia documentata proprio di questa pazienza. In una campagna precedente che Sygnia ha divulgato a giugno 2024, lo stesso attore ha mantenuto circa tre anni di accesso nascondendosi dentro due bilanciatori di carico F5 BIG-IP esposti su Internet — aggiungendo i propri tool VELVETSTING e VELVETTAP a /etc/rc.local e pivotando dall'appliance verso file server interni infetti da PlugX. Lo schema si ripete: vivere dentro il dispositivo di rete o il componente di sistema fidato per default e raramente ispezionato — il bilanciatore, lo switch, la libreria di login — e aspettare.

Si confronti il dwell time con la baseline del settore. M-Trends di Mandiant colloca il dwell time mediano globale intorno agli undici giorni. Quello di Velvet Ant era circa 3.650. Il divario non è un problema di tuning che si risolve con una regola SIEM più veloce. È la differenza tra un controllo che osserva e un controllo che presume.

Il controllo su cui contavano	Cosa doveva fare	Perché non ha visto nulla
Topologia air-gap	Impedire ogni accesso remoto	Aggirata via relay Nginx → FastCGI → SSH su infrastruttura fidata
EDR / AV host	Segnalare binari malevoli	Nessun dropper malevolo; le backdoor vivono dentro pam_unix.so, sshd
Log di autenticazione	Registrare chi fa login	Scritti dallo stack di auth con backdoor; i login attacker sembrano legittimi
Patch / gestione vuln	Chiudere i CVE sfruttabili	Nessun exploit usato — la persistenza è abuso di fiducia, non una vulnerabilità
Audit periodico	Verificare la tenuta della segmentazione	Point-in-time; il relay è un comportamento runtime, invisibile tra un audit e l'altro

Tutto ciò che sta nella colonna di sinistra vive sull'host compromesso, o si fida di esso. Niente di tutto questo sopravvive a un avversario che possiede il livello di autenticazione.

Osservare il traffico dentro l'air-gap

Ecco l'asimmetria che Velvet Ant non poteva ingegnerizzare via. Ha silenziato i log, si è nascosto dentro binari fidati e non ha prodotto artefatti malware — ma doveva comunque muoversi. Ogni login con backdoor che contava, ogni salto laterale attraverso il proxy SOCKS5 smbd -D, ogni connessione SSH del binario uptime dal ponte verso il segmento, ogni callout GS-Netcat verso la relay network — tutto questo è una conversazione di rete. L'attaccante controllava ciò che gli host registravano su sé stessi. Non controllava la forma del traffico tra gli host.

E quel traffico ha una forma che l'amministrazione di routine non produce. Su una rete isolata che dovrebbe avere un insieme piccolo e prevedibile di flussi interni, i segnali sono netti:

• un server "web" in DMZ che apre sessioni SSH verso la rete segmentata con una cadenza che nessun umano ha impostato;
• un host interno che proxa via SOCKS connessioni verso molti altri in un fan-out che un amministratore reale non genera mai;
• sessioni cifrate di lunga durata verso un host che, storicamente, riceveva soltanto traffico;
• un daemon nominato come un processo Samba che parla un protocollo che non è SMB.

È esattamente il problema per cui è stato costruito il pilastro AI Traffic Analysis di Zero Hunt. Un modello di deep learning proprietario, addestrato su miliardi di sequenze PCAP, esegue quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — direttamente sulla GPU dell'appliance a 2,7+ Gbit/s. Non ha bisogno di una firma per Velvet Ant; valuta il comportamento. Il percorso di relay dalla DMZ verso il segmento isolato, il fan-out laterale SOCKS5, il tunnel cifrato che non corrisponde all'applicazione che dichiara di possedere la porta — sono anomalie sul traffico a prescindere da quanto pulito appaia l'host, perché il rilevatore non sta sull'host che l'attaccante possiede.

Il dettaglio di deployment è ciò che rende tutto questo utilizzabile nell'ambiente che Velvet Ant ha scelto. Zero Hunt gira come appliance 100% on-prem, senza callback verso il cloud, senza telemetria esterna e con pieno supporto air-gap — aggiornamenti consegnati via bundle offline firmato. Uno strumento di detection o validazione che chiama casa verso un backend SaaS non può girare affatto in una rete davvero isolata; è escluso dalla stessa proprietà che il difensore cerca di proteggere. L'ironia dell'Operazione Highland è che l'air-gap ha tenuto fuori il tooling difensivo in modo più affidabile di quanto abbia tenuto fuori l'attaccante.

La prima metà della storia appartiene al secondo pilastro. L'intera intrusione ruotava attorno a un percorso Nginx/FastCGI esposto su Internet che poteva essere indotto a raggiungere l'interno, e attorno a uno stack di autenticazione che nessuno aveva testato in modalità assumed-breach. Il pentest generativo a 10 agenti di Zero Hunt valida quella superficie in modo continuo anziché in sede di audit: gli agenti Recon ed Exploit sondano il livello web esposto proprio per le condizioni di relay delle richieste da cui dipendeva il ponte, e gli agenti Pivot e Post-Exploit provano il percorso da un punto d'appoggio verso il segmento presunto isolato — trovando la rotta logica attraverso l'air-gap prima che lo faccia un avversario paziente. Ogni catena è ricollaudata nell'AI Gym prima di essere eseguita, e ogni finding è firmato ECDSA per la catena di custodia che, prima o poi, un regolatore per i soggetti essenziali chiederà.

Un air-gap ferma un pacchetto. Non ferma un relay costruito con infrastruttura fidata, e non rileva un inquilino che possiede il sistema di login da un decennio. Se le tue reti isolate sono protette dalla topologia e da un audit annuale, è questa la conversazione da avere; per come è architettata l'appliance air-gap, vedi la panoramica della piattaforma. Il fallimento adiacente — un dwell lungo e silenzioso misurato in anni anziché in giorni — è trattato nella nostra analisi degli 858 giorni di dwell time a UNMC.