(in)sicurezza digitale

2026-06-16 07:43:34

Operation Highland: Velvet Ant spia una rete air-gapped per 10 anni backdoorando PAM e OpenSSH

Si parla di:
Toggle

Per quasi un decennio, un gruppo di spionaggio informatico legato alla Cina ha operato indisturbato all’interno di una rete isolata di infrastrutture critiche, compromettendo il cuore stesso del meccanismo di autenticazione Linux. La scoperta, firmata dai ricercatori di Sygnia, racconta di una pazienza operativa rara e di una sofisticazione tecnica che ridefinisce il concetto di persistenza avanzata.

Velvet Ant: chi è e cosa ha fatto in precedenza

Velvet Ant è un cluster di attività di cyberspionaggio attribuito a un attore nation-state cinese, già documentato da Sygnia nel 2024 in una campagna che aveva preso di mira dispositivi F5 BIG-IP rimasti compromessi per tre anni senza essere rilevati. Nello stesso anno, Cisco aveva segnalato lo sfruttamento di uno zero-day nei propri switch NX-OS da parte dello stesso gruppo. La nuova ricerca, denominata Operation Highland, supera però per portata e durata tutto ciò che era stato osservato in precedenza: dieci anni di accesso continuativo a una rete air-gapped di infrastrutture critiche appartenente a una grande organizzazione.

La catena di attacco: dall’esterno alla rete isolata

L’intrusione ha avuto inizio nel 2016 con la compromissione di server esposti su internet. Su questi sistemi, Velvet Ant ha distribuito una versione modificata di GS-Netcat, uno strumento legittimo per creare tunnel cifrati, trasformato in una reverse shell persistente. Il file veniva mascherato come utility di sistema auditdb e collocato in /usr/sbin/, stabilendo la persistenza tramite un servizio systemd malevolo oppure modificando gli script di avvio SysVinit a seconda del sistema.

Per muoversi lateralmente senza generare traffico diretto verso internet, gli attaccanti hanno installato un proxy SOCKS5 scritto in Perl che mascherava il proprio processo come smbd -D, usando filename, porte e nomi di processo diversi su ogni host per ostacolare il rilevamento.

La parte più sofisticata riguarda però la costruzione del percorso di accesso verso la rete isolata. Velvet Ant ha modificato la configurazione di un server Nginx internet-facing per proxare richieste HTTP specificamente costruite verso un server backend compromesso. Questo backend aveva a sua volta Nginx configurato per inoltrare le richieste a un processo FastCGI (fcgiwrap) in ascolto su una porta separata. Il FastCGI wrapper agiva come bridge di esecuzione, lanciando un binario personalizzato chiamato uptime che stabiliva connessioni SSH verso sistemi nella rete isolata, usando parametri forniti tramite HTTP POST.

“Concatenando queste modifiche, Velvet Ant ha stabilito un percorso di esecuzione remota nell’ambiente segregato tramite semplici richieste HTTP, senza mai richiedere una connessione diretta alla rete di infrastrutture critiche.” — Sygnia

Il colpo di genio: backdoor nell’autenticazione Linux

Una volta ottenuto l’accesso alla rete isolata, Velvet Ant ha spostato il focus verso la persistenza a lungo termine e la raccolta di credenziali, attaccando direttamente il sistema di autenticazione Linux: i Pluggable Authentication Modules (PAM).

I ricercatori di Sygnia hanno identificato nove varianti distinte del modulo malevolo pam_unix.so, ciascuna compilata in un ambiente di build separato — un indicatore di un attore con risorse abbondanti e operativamente disciplinato. Alcune varianti funzionavano come backdoor pura, accettando una password hardcoded che consentiva l’accesso bypassando l’autenticazione normale. Altre raccoglievano e memorizzavano localmente le credenziali di tutti gli utenti in un file nascosto.

In parallelo, gli attaccanti hanno sostituito i componenti di OpenSSH — inclusi ssh, sshd e scp — con versioni trojanizzate capaci di:

• Catturare e registrare le password utilizzate nelle sessioni SSH
• Loggare tutti i comandi eseguiti dagli amministratori
• Nascondere le tracce dell’attività degli attaccanti
• Disabilitare SELinux quando avviati con privilegi root
• Permettere agli stessi attaccanti di disattivare il logging delle proprie sessioni tramite un flag speciale

Velvet Ant ha inoltre aggiunto le proprie chiavi pubbliche SSH negli authorized_keys dei server compromessi, garantendosi un accesso persistente senza password indipendente dai moduli PAM manipolati.

Dieci anni invisibili: perché il rilevamento era così difficile

La scelta di compromettere i componenti di autenticazione stessi, piuttosto che distribuire malware convenzionale, ha rappresentato il fattore chiave nella longevità dell’operazione. I tool di sicurezza cercano processi anomali e comunicazioni di rete sospette: un’autenticazione PAM modificata che accetta una password hardcoded sembra semplicemente un login legittimo. I log di sistema mostravano accessi normali. Non c’erano payload da rilevare, non c’erano connessioni C2 evidenti dall’interno della rete isolata.

L’uso di nomi di file, porte e nomi di processo differenti su ogni host rendeva impossibile correlare l’attività attraverso la rete senza una visione completa e coordinata dell’intero ambiente.

Il cleanup: più pericoloso della compromissione

Sygnia descrive la fase di remediation come particolarmente complessa. Velvet Ant aveva sostituito tanti componenti critici con versioni personalizzate che la loro rimozione scorretta avrebbe potuto bloccare l’accesso degli amministratori legittimi, causando interruzioni operative in sistemi di infrastruttura critica.

Il team di risposta ha dovuto costruire un laboratorio di test per validare il processo di sostituzione dei binari, profilare ogni host per identificare le versioni corrette dei componenti, testare le procedure di ripristino e preparare rollback prima di tentare qualsiasi intervento in produzione. Ogni step veniva validato verificando che l’autenticazione SSH continuasse a funzionare correttamente.

Indicatori di compromissione e due righe difensive

Sygnia raccomanda di trattare componenti come PAM, OpenSSH e Windows LSASS come asset di sicurezza critici da proteggere con:

• File Integrity Monitoring (FIM) sui binari di autenticazione e sui moduli PAM
• EDR con regole specifiche per modifiche a /lib/security/pam_unix.so, /usr/sbin/sshd, /usr/bin/ssh
• MFA obbligatoria per l’accesso privilegiato, anche in reti air-gapped
• Backup immutabili verificati periodicamente con procedure di ripristino testate offline
• Monitoring delle chiavi SSH nei file authorized_keys su tutti i server

# File e percorsi da monitorare con FIM
/lib/security/pam_unix.so
/lib/x86_64-linux-gnu/security/pam_unix.so
/usr/sbin/sshd
/usr/bin/ssh
/usr/bin/scp
/etc/ssh/sshd_config
/root/.ssh/authorized_keys
/home/*/.ssh/authorized_keys

# Processi sospetti identificati nell'operazione
smbd -D   # proxy SOCKS5 mascherato
uptime    # binario custom per SSH verso rete isolata
auditdb   # GS-Netcat reverse shell

# Pattern di accesso sospetto
# Login PAM con password non corrispondente agli hash in /etc/shadow
# Sessioni SSH con flag speciali non documentati
# Traffico HTTP verso Nginx con parametri POST insoliti verso backend interni

Operation Highland dimostra che la sicurezza delle reti air-gapped non può essere data per scontata. Quando un attore sufficientemente motivato riesce a ottenere l’accesso iniziale, la mancanza di connettività internet non è un ostacolo insuperabile: è semplicemente un problema da risolvere con creatività tecnica. E come questa operazione mostra, quella creatività può restare nascosta per un decennio.

Spcnet.it

2026-06-16 07:45:06

Attacco supply chain all’AUR di Arch Linux: 1.500 pacchetti compromessi con rootkit eBPF

Cosa è successo: l’attacco all’AUR in sintesi

Il team di sicurezza di Arch Linux ha disabilitato le nuove registrazioni all’Arch User Repository (AUR) a seguito di una compromissione su larga scala. Tra il 13 e il 15 giugno 2026 gli attaccanti hanno dirottato o creato ex novo oltre 1.500 pacchetti gestiti dalla community per distribuire payload malevoli: information stealer e rootkit basati su eBPF. I repository ufficiali di Arch (core, extra, multilib) non sono stati colpiti grazie ai processi di review più stringenti dei maintainer ufficiali.

L’attacco si è sviluppato in due ondate distinte, entrambe basate su dipendenze JavaScript malevole inserite nei PKGBUILD:

• Prima ondata: uso di un pacchetto denominato atomic-lockfile per eseguire binari ostili al momento del build
• Seconda ondata (più sofisticata): introduzione di un binario separato tramite il pacchetto js-digest, con tecniche di evasion più avanzate

Gli script malevoli erano progettati per scaricare e installare silenziosamente il malware sui sistemi degli utenti che avevano compilato i pacchetti compromessi dal sorgente.

Perché l’AUR è strutturalmente vulnerabile agli attacchi supply chain

L’AUR è un repository non ufficiale e non supportato di build script (PKGBUILD) contribuiti dalla community. Chiunque può creare un account e pubblicare un pacchetto; non esiste una review obbligatoria da parte del team Arch prima della pubblicazione. Questo modello “aperto” ha permesso all’ecosistema AUR di crescere fino a oltre 80.000 pacchetti, ma lo rende intrinsecamente più esposto rispetto ai repository ufficiali.

I vettori tipici di compromissione dell’AUR sono:

• Account hijacking: un attaccante prende controllo di un account maintainer inattivo (o con credenziali deboli) e pubblica commit malevoli su pacchetti legittimi e popolari
• Pacchetti typosquatting: creazione di nuovi pacchetti con nomi simili a quelli legittimi, sfruttando errori di battitura o la confusione tra nomi simili
• Dependency confusion: sostituzione di dipendenze interne con versioni malevole omonime pubblicate su registri pubblici

In questo caso l’attacco ha sfruttato principalmente l’account hijacking, con l’aggravante della catena di dipendenze JavaScript — un vettore sempre più usato in attacchi supply chain anche su ecosistemi npm e PyPI.

I payload: information stealer e rootkit eBPF

La scelta dei payload è tecnicament rilevante e vale la pena approfondirla.

Information Stealer

Gli information stealer raccolti in questa campagna erano progettati per estrarre credenziali, cookie di sessione browser, chiavi SSH, wallet di criptovalute e dati di configurazione da macchine Linux. Il targeting di sistemi Arch Linux (tipicamente macchine di sviluppatori, sysadmin e power user) massimizza il valore dei dati sottratti.

Rootkit eBPF

La componente più preoccupante è il rootkit basato su eBPF (Extended Berkeley Packet Filter). eBPF è una tecnologia del kernel Linux che consente l’esecuzione di programmi sandboxati direttamente nel kernel, originariamente pensata per networking e observability (usata da strumenti come Cilium, Falco, bpftrace). Abusata per scopi malevoli, permette di:

• Intercettare chiamate di sistema senza modificare file sul disco
• Nascondere processi, file e connessioni di rete agli strumenti di monitoring tradizionali
• Esfiltrare dati a livello di kernel, bypassando molti EDR
• Mantenere la persistenza in modo difficile da rilevare, dato che i programmi eBPF non appaiono nei normali listing dei processi

Un rootkit eBPF richiede privilegi elevati per essere caricato, ma una volta in esecuzione è significativamente più difficile da rilevare rispetto a un rootkit tradizionale basato su moduli kernel (LKM). Strumenti come bpftool permettono di enumerare i programmi eBPF caricati, ma un rootkit sofisticato può nascondere anche se stesso da questa enumerazione.

Come verificare se il proprio sistema è compromesso

Se si utilizza Arch Linux con pacchetti AUR installati nel periodo della compromissione, seguire questa procedura:

1. Verificare la presenza dei binari malevoli identificati

# Cercare i file associati alle due ondate dell'attacco
find / -name "atomic-lockfile" -o -name "js-digest" 2>/dev/null

# Cercare processi insoliti
ps aux | grep -E "(\.tmp|/tmp/\.|hidden)"

2. Enumerare i programmi eBPF caricati

# Listare tutti i programmi eBPF attivi
sudo bpftool prog list

# Listare le mappe eBPF
sudo bpftool map list

# Ispezionare un programma specifico (sostituire ID con quello trovato)
sudo bpftool prog dump xlated id <ID>

Programmi eBPF con nomi generici o vuoti, o di tipo kprobe/tracepoint non associati a tool di sistema noti, meritano approfondimento.

3. Controllare i pacchetti AUR installati recentemente

# Pacchetti installati nelle ultime 72 ore
grep -E "^\[ALPM\] installed" /var/log/pacman.log | tail -50

# Verificare l'integrità dei file installati
pacman -Qkk 2>&1 | grep -v "0 altered"

4. Seguire le indicazioni ufficiali del team Arch

Il team di sicurezza Arch ha pubblicato checklist ufficiali per gli utenti colpiti, disponibili sul portale di sicurezza Arch Linux. Le azioni di cleanup includono la rimozione dei pacchetti compromessi, la revoca delle chiavi SSH potenzialmente esfiltrate e il cambio delle credenziali esposte.

Best practice per chi usa l’AUR

Questo attacco è un promemoria di regole che esistono da anni ma vengono spesso ignorate per comodità:

• Leggere sempre i PKGBUILD prima di installare. È la prima difesa. Un PKGBUILD malevolo è spesso riconoscibile da download di binari da URL non ufficiali, pipe a shell, o dipendenze insolite.
• Usare helper AUR con revisione esplicita. Tool come paru mostrano il diff del PKGBUILD prima di procedere. Non ignorare questo step.
• Preferire pacchetti con molti voti e maintainer attivi. Non è una garanzia assoluta, ma riduce il rischio.
• Usare ambienti isolati per il build. Tool come aurutils con makechrootpkg compilano i pacchetti in un chroot pulito, limitando l’impatto di un PKGBUILD malevolo.
• Monitorare le dipendenze JavaScript nei PKGBUILD. Pacchetti che scaricano moduli npm o yarn durante il build meritano attenzione extra, soprattutto se le dipendenze non sono verificate tramite hash.
• Abilitare audit di sistema. auditd con regole appropriate può rilevare comportamenti anomali durante e dopo l’installazione di pacchetti.

Implicazioni più ampie per la sicurezza della supply chain Linux

L’attacco all’AUR si inserisce in un trend preoccupante di compromissioni della supply chain su piattaforme open source. Nell’ultimo anno abbiamo visto attacchi analoghi su npm, PyPI, RubyGems e GitHub Actions. La peculiarità dell’ecosistema Linux è che molti degli utenti AUR sono sviluppatori e sysadmin con accesso privilegiato a infrastrutture aziendali: la compromissione di una workstation di uno sviluppatore può trasformarsi rapidamente in un punto di ingresso laterale verso sistemi di produzione.

La risposta del team Arch — blocco delle registrazioni, revert dei commit malevoli, ban degli account — è stata rapida ma reattiva. Il dibattito nella community si concentra ora su misure preventive: firma obbligatoria dei PKGBUILD, review automatizzata tramite analisi statica, e requisiti più stringenti per l’acquisizione di pacchetti esistenti. Nessuna di queste misure è banale da implementare mantenendo la natura aperta dell’AUR, ma l’attacco ha reso evidente il costo del modello attuale.

---

Fonti: 4sysops · The Hacker News · The Register

Arch Linux suspends AUR registrations following massive supply chain attack – 4sysops

The Arch Linux security team has disabled new account registrations for the Arch User Repository (AUR) following a large-scale supply chain compromise. Attacker

^{IT News (4sysops)}

Spcnet.it

2026-06-16 07:45:27

DNS over HTTPS su Windows Server 2025: configurazione completa e considerazioni enterprise

Cos’è DNS over HTTPS e perché cambia le regole del gioco

Il DNS tradizionale risolve i nomi di dominio inviando query in chiaro su UDP o TCP sulla porta 53. Chiunque si trovi sul percorso di rete — un ISP, un operatore Wi-Fi aziendale o un attaccante con accesso al segmento — può leggere o manipolare quelle query. DNS over HTTPS (DoH) risolve questo problema incapsulando le query DNS all’interno di connessioni HTTPS cifrate con TLS: lo stesso meccanismo di crittografia utilizzato dalla normale navigazione web.

Con l’aggiornamento cumulativo di giugno 2026 (KB5094125) per Windows Server 2025, Microsoft ha reso disponibile DoH in modalità General Availability per il ruolo DNS Server on-premises. Non è più necessario affidarsi a resolver di terze parti: la cifratura DNS parte ora direttamente dalla propria infrastruttura interna.

DoH vs DNS over TLS: quale scegliere in ambienti enterprise

Esiste un protocollo simile, DNS over TLS (DoT), che cifra anch’esso il traffico DNS ma utilizza la porta dedicata 853. Questa scelta ha una conseguenza pratica rilevante: i sistemi di monitoraggio di rete possono identificare e filtrare il traffico DoT separatamente, mantenendo la visibilità sulle query DNS.

DoH, invece, transita sulla porta 443 e si fonde con il normale traffico HTTPS. Da un lato questo lo rende più difficile da bloccare; dall’altro riduce la visibilità degli strumenti di ispezione DNS aziendali. Prima di scegliere DoH in un ambiente enterprise, occorre valutare se la propria security operations si affida all’ispezione del traffico DNS per rilevare minacce (data exfiltration via DNS, C2 beaconing, ecc.). In quel caso, DoT potrebbe essere preferibile, oppure occorre affiancare soluzioni di monitoring che lavorino a livello applicativo.

Requisiti di sistema

Per abilitare DoH sul ruolo DNS Server di Windows Server 2025 sono necessari:

• Windows Server 2025 con l’aggiornamento cumulativo KB5094125 (9 giugno 2026) o successivo
• Un certificato TLS valido con Extended Key Usage “Server Authentication” e un Subject Alternative Name (SAN) che corrisponda al template URI DoH
• La chiave privata del certificato presente nel certificate store del computer locale, senza strong private key protection abilitata
• Il certificato emesso da una CA trusted da server e client (Microsoft Enterprise CA, DigiCert, Let’s Encrypt — tutte funzionano)
• Porta TCP 443 aperta in ingresso sul firewall del server
• Accesso amministrativo al server

Da notare: al momento non è disponibile alcuna interfaccia grafica nel DNS Manager per gestire DoH. Tutta la configurazione avviene tramite PowerShell.

Configurazione passo per passo

Step 1 — Importare il certificato TLS

Copiare il file .pfx del certificato sul server e importarlo nel certificate store del computer locale:

Import-PfxCertificate `
    -FilePath "C:\Certs\dns-server.pfx" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -Password (Read-Host -AsSecureString "Password PFX")

Step 2 — Associare il certificato alla porta 443

Generare un GUID univoco e associare il certificato alla porta tramite netsh:

$guid = New-Guid
$cert = Get-ChildItem -Path Cert:\LocalMachine\My |
        Where-Object { $_.Subject -match "dns.dominio.local" }

netsh http add sslcert ipport=0.0.0.0:443 `
    certhash=$($cert.Thumbprint) `
    appid="{$guid}"

Per vincolare il binding a un indirizzo IP specifico anziché a tutti gli indirizzi, sostituire 0.0.0.0 con l’indirizzo desiderato.

Step 3 — Aprire la porta 443 nel firewall di Windows

New-NetFirewallRule `
    -DisplayName "DNS over HTTPS" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow

Step 4 — Abilitare DoH e configurare il template URI

Sostituire dns.dominio.local con il hostname presente nel SAN del certificato:

Set-DnsServerEncryptionProtocol `
    -EnableDoh $true `
    -UriTemplate "https://dns.dominio.local:443/dns-query"

Restart-Service -Name DNS

Step 5 — Verificare la configurazione

Get-DnsServerEncryptionProtocol

Aprire il Visualizzatore eventi sotto Applications and Services Logs > DNS Server e verificare la presenza dell’evento ID 822, che conferma l’avvio del servizio DoH.

Configurare i client Windows per usare DoH

Windows supporta DoH lato client da Windows 11 (e da Windows Server 2022 nel ruolo di client DNS). Esistono due metodi principali per puntare i client al resolver DoH interno:

Interfaccia grafica (Windows 11)

Navigare in Impostazioni > Rete e Internet > Ethernet (o Wi-Fi) > Assegnazione server DNS, inserire l’indirizzo IP del server DNS e impostare la cifratura DNS su Solo cifrato (DNS over HTTPS).

Group Policy (Windows Server 2022 e successivi)

Applicare il criterio in Configurazione computer > Criteri > Modelli amministrativi > Rete > Client DNS > Configura risoluzione dei nomi DNS over HTTPS (DoH). Il criterio offre tre opzioni:

• Consenti DoH — usa DoH se il resolver lo supporta
• Proibisci DoH — impedisce l’uso di DoH
• Richiedi DoH — richiede sempre DoH

Attenzione: Microsoft sconsiglia di impostare “Richiedi DoH” su computer appartenenti a un dominio Active Directory se i server DNS non supportano ancora DoH come resolver. AD dipende pesantemente dal DNS, e forzare DoH su una rete senza resolver compatibile interrompe la risoluzione dei nomi e, di conseguenza, l’autenticazione e i GPO. Ora che Windows Server 2025 supporta il lato server, l’opzione “Richiedi DoH” diventa praticabile in ambienti completamente migrati.

Limitazioni attuali da tenere presenti

Prima di pianificare un deployment in produzione, è importante conoscere i limiti della GA attuale:

• Nessuna cifratura verso gli upstream resolver. DoH cifra solo il traffico tra i client e il DNS Server Windows. Le query che il DNS Server invia ai forwarder upstream o ai server autorevoli viaggiano ancora in chiaro sulla porta 53. Microsoft ha annunciato il supporto per query upstream cifrate in un aggiornamento futuro, ma senza timeline confermata.
• Nessuna interfaccia grafica. Il DNS Manager non include ancora le impostazioni DoH. Tutta la gestione richiede PowerShell.
• Punti ciechi nel monitoraggio. Il traffico DoH su porta 443 è cifrato e indistinguibile dall’HTTPS web. Gli strumenti di monitoring DNS a livello di rete perdono visibilità. Valutare l’impatto sulla security operations prima di abilitare DoH in modo capillare.
• DoH non sostituisce DNSSEC. DoH cifra il trasporto; DNSSEC verifica l’integrità delle risposte DNS con firme crittografiche. Le due tecnologie sono complementari e indipendenti: DoH senza DNSSEC protegge dalla sorveglianza ma non dalla manipolazione delle risposte da parte del server stesso.

Considerazioni per il deployment

Un approccio pragmatico per l’introduzione di DoH in un ambiente enterprise prevede di partire con la policy “Consenti DoH” — non forzata — su un gruppo pilota di macchine, verificare che i log di audit DNS continuino a funzionare (adattando gli strumenti di monitoraggio se necessario) e solo successivamente estendere il rollout. Per gli ambienti con requisiti di compliance legati all’ispezione del traffico DNS, è consigliabile documentare la strategia di visibilità alternativa prima di procedere con “Richiedi DoH”.

Il supporto nativo sul DNS Server on-premises è un passo significativo: elimina la dipendenza da resolver cloud di terze parti e permette di mantenere la cifratura DNS all’interno del perimetro aziendale, con pieno controllo sul certificato e sul logging.

---

Fonte: DNS over HTTPS (DoH) for Windows Server 2025 DNS Server is generally available — 4sysops

DNS over HTTPS (DoH) for Windows Server 2025 DNS Server is generally available – 4sysops

DNS over HTTPS (DoH) -- a protocol that encrypts DNS queries inside HTTPS connections -- is now generally available for the Windows Server DNS Server role. Star

^{IT Experts (4sysops)}