Driver infetti: protocollo di verifica per PMI

TL;DR: un driver scaricato dal sito del produttore non è automaticamente sicuro. Il caso GEEKOM mostra un problema concreto: un pacchetto segnalato dai motori di sicurezza è rimasto raggiungibile da una vecchia pagina indicizzata dai motori di ricerca. Per una PMI la risposta non è analizzare ogni file come un laboratorio forense. Serve un gate semplice: download dal percorso corrente del vendor, hash registrato, firma verificata, scansione, test su un dispositivo pilota e rollout tracciato. Se il pacchetto fallisce uno di questi controlli, non entra in produzione.

Il 17 agosto 2026 Tom’s Hardware ha riportato il caso di un pacchetto LAN per alcuni mini PC GEEKOM. Secondo la testata, il file conteneva la backdoor Asruex ed era stato rilevato da più servizi di analisi. GEEKOM, in una comunicazione pubblicata sul proprio subreddit ufficiale, ha confermato che il file segnalato proveniva da una risorsa di supporto obsoleta ancora raggiungibile tramite vecchi link e risultati di ricerca. L’azienda ha rimosso la pagina e ha invitato chi aveva scaricato il pacchetto a non eseguirlo, eliminarlo, fare una scansione completa e usare il supporto corrente.

Le due fonti non dicono esattamente la stessa cosa. La testata attribuisce un nome al malware e descrive le rilevazioni; il produttore parla di file segnalato e di pagina legacy. Questa distinzione conta. Non serve gonfiare l’incidente per ricavarne una regola utile: la navigazione ufficiale era stata aggiornata, ma il vecchio asset era ancora trovabile. Per chi gestisce postazioni aziendali, un dominio legittimo e un risultato ben posizionato su Google non bastano come catena di fiducia.

Perché un driver ha un rischio diverso

Un driver non è un normale documento scaricato dal web. Collega il sistema operativo a rete, storage, grafica, audio o altre periferiche. L’installer richiede spesso privilegi amministrativi e può aggiungere componenti che lavorano vicino al kernel. Un controllo superficiale sul nome del file o sul lucchetto HTTPS non dice chi lo ha prodotto, se è stato modificato o se appartiene ancora al canale di distribuzione corrente.

Windows analizza la firma del pacchetto prima di inserirlo nel Driver Store. La documentazione Microsoft sulle categorie di firma distingue pacchetti firmati da un’autorità Windows, publisher attendibili o sconosciuti, file alterati e file senza firma valida. Una firma valida collega il file a un publisher e permette di controllare l’integrità. Non certifica che quel software sia privo di vulnerabilità o che ogni scelta del produttore sia sicura.

Questo è il primo errore da evitare: trasformare la firma in un bollino assoluto. Microsoft mantiene anche una blocklist di driver vulnerabili e malevoli proprio perché software legittimo e firmato può contenere difetti sfruttabili. La verifica corretta combina provenienza, firma, reputazione, necessità operativa e comportamento dopo l’installazione.

Il confine di fiducia parte dal percorso di download

La pagina trovata con una ricerca non dovrebbe essere il punto finale del controllo. Parti dalla home del produttore, entra nella sezione Supporto e cerca il modello esatto. Confronta dominio, codice del prodotto, sistema operativo, versione del pacchetto e data. Se il link ricevuto via email, ticket o motore di ricerca non coincide con il percorso corrente, fermati e chiedi conferma al vendor.

Nel caso GEEKOM il produttore ha spiegato che la vecchia risorsa non era più nella normale navigazione del supporto, ma risultava ancora indicizzata. È un caso utile anche per chi gestisce WordPress: togliere un link dal menu non ritira una risorsa. Un file resta distribuibile finché l’URL risponde, le cache lo conservano o i motori lo propongono. Il vendor deve disattivare l’asset, invalidare le copie e pubblicare un avviso preciso; il cliente deve verificare la provenienza ogni volta.

Per una PMI conviene registrare almeno quattro dati prima dell’installazione: URL finale, data e ora del download, modello hardware e nome dell’operatore. Se il produttore pubblica un hash, va salvato insieme al pacchetto. Se non lo pubblica, calcola comunque il tuo SHA-256: non prova che il file sia buono, ma permette di sapere esattamente quale versione è stata testata e distribuita.

Gate 1: registra hash e firma prima di eseguire

Su Windows puoi calcolare lo SHA-256 con PowerShell senza installare strumenti aggiuntivi:

Get-FileHash -LiteralPath "C:\Pacchetti\driver.zip" -Algorithm SHA256

Microsoft documenta Get-FileHash come comando per calcolare l’impronta del contenuto; SHA-256 è anche l’algoritmo predefinito. Salva il risultato nel ticket di modifica o nell’inventario. Se due tecnici hanno scaricato file con lo stesso nome ma hash diversi, non procedere finché non hai spiegato la differenza.

Estrai il pacchetto in una cartella di staging, senza lanciare l’installer, e controlla la firma dei file eseguibili:

Get-ChildItem "C:\Pacchetti\driver" -Recurse -File |
  Where-Object { $_.Extension -in '.exe', '.dll', '.sys', '.cat' } |
  ForEach-Object {
    Get-AuthenticodeSignature -LiteralPath $_.FullName |
      Select-Object Path, Status, StatusMessage,
        @{Name='Signer';Expression={$_.SignerCertificate.Subject}}
  }

Il cmdlet Get-AuthenticodeSignature restituisce lo stato della firma e il certificato del firmatario. Il gate passa solo se lo stato è Valid, il publisher è quello atteso e il pacchetto corrisponde all’hardware. Un certificato valido intestato a un soggetto inatteso non va ignorato. Un file senza firma non è automaticamente malware, ma in un pacchetto driver aziendale richiede una spiegazione documentata del fornitore.

Gate 2: scansione senza regalare dati

Fai una scansione locale aggiornata prima dell’esecuzione. Se la policy aziendale permette servizi multi-engine, invia prima l’hash e controlla se il file è già conosciuto. Caricare l’intero pacchetto su un servizio esterno può esporre software riservato, nomi interni o componenti distribuiti sotto accordi specifici. L’hash riduce questo rischio, ma non offre una risposta quando il campione non è mai stato analizzato.

Microsoft offre anche Sigcheck nella suite Sysinternals: mostra firma, catena del certificato, versione e hash, e può interrogare VirusTotal. Le opzioni che caricano campioni vanno abilitate solo dopo aver verificato policy e termini del servizio. In una piccola azienda il controllo deve restare comprensibile: firma valida, hash tracciato, scansione locale pulita e nessuna rilevazione multi-engine inspiegata.

Una rilevazione isolata può essere un falso positivo. Non va né promossa a prova definitiva né ignorata. Blocca il rollout, conserva l’hash, apri un ticket con il vendor e chiedi un nuovo pacchetto o una conferma firmata. La velocità corretta è quella che evita di installare lo stesso dubbio su venti postazioni.

Gate 3: un dispositivo pilota, non l’intera azienda

Il primo test va fatto su una macchina non critica, ripristinabile e separata dai dati reali. Crea un punto di ripristino o, meglio, un’immagine nota del sistema. Annota versione del driver attuale, periferica interessata e motivo dell’aggiornamento. Se non esiste un problema da risolvere, una vulnerabilità corretta o una funzione necessaria, puoi rimandare l’installazione.

Dopo il riavvio controlla almeno connettività, Event Viewer, servizi nuovi, attività pianificate, elementi di avvio e alert dell’endpoint protection. Verifica che il dispositivo funzioni e che il driver attivo riporti provider e versione previsti. Tieni il pilota in osservazione per un intervallo coerente con il rischio: qualche ora per una correzione urgente già validata, uno o due giorni per un aggiornamento ordinario.

Se usi Microsoft Intune, le policy dedicate agli aggiornamenti driver permettono approvazione automatica o manuale e distribuzione centralizzata tramite Windows Update e Autopatch. Per una flotta piccola sceglierei l’approvazione manuale: il tempo risparmiato da un rollout immediato non compensa il costo di un driver problematico distribuito ovunque.

Gate 4: rollout a gruppi e possibilità di rollback

Dopo il pilota, distribuisci il pacchetto a gruppi. Un esempio semplice è 1 dispositivo, poi il 20% della flotta, poi il resto. Tra un gruppo e l’altro controlla errori di installazione, crash, perdita di rete e alert di sicurezza. Definisci prima la soglia di stop: un solo rilevamento malware, una firma diversa, un errore ripetibile sulla funzione critica o un aumento anomalo dei crash fermano la distribuzione.

Il rollback deve essere preparato prima del click. Conserva versione precedente, procedura di rimozione, accesso locale di emergenza e alternativa di rete se stai aggiornando LAN o Wi-Fi. Un tecnico collegato soltanto via desktop remoto non dovrebbe sostituire il driver di rete senza una via di recupero. Questa non è burocrazia: è la differenza tra un test reversibile e una mattina persa a raggiungere fisicamente ogni postazione.

Il log minimo del rollout contiene hash approvato, firma, origine, dispositivi coinvolti, orario, esito e operatore. Lo stesso meccanismo usato per affiancare controlli continui e pentest vale qui: la verifica manuale profonda resta utile, ma una checklist ripetibile impedisce che ogni aggiornamento dipenda dalla memoria del tecnico.

Se il pacchetto è già stato eseguito

Se un file viene segnalato dopo l’installazione, non limitarti a cancellare lo ZIP. Isola il dispositivo dalla rete, registra hash, percorso, utente e orario, e informa chi gestisce la sicurezza. Esegui la scansione prevista dalla tua procedura di risposta agli incidenti. Se il sospetto riguarda un installer con privilegi amministrativi o una backdoor, considera compromesse le credenziali usate da quella macchina finché l’analisi non dimostra il contrario.

Per una postazione da cui si amministrano WordPress, hosting, email o automazioni, la priorità è alta. Ruota le credenziali da un dispositivo pulito, revoca le sessioni, controlla accessi e modifiche recenti e verifica i secret usati dagli script. Non copiare alla cieca profili browser o cartelle applicative sul sistema reinstallato: potresti riportare dentro lo stesso problema.

GEEKOM ha consigliato una scansione completa e il contatto con il supporto a chi aveva già eseguito il file. Tom’s Hardware ha suggerito, per i modelli indicati e il pacchetto coinvolto, almeno una scansione offline e idealmente una reinstallazione completa. La decisione tra bonifica e reimage dipende dalle prove disponibili, dal livello di privilegio ottenuto e dal valore degli account esposti. Quando non puoi dimostrare lo stato pulito, ricostruire da un’immagine affidabile è spesso la scelta più economica.

La checklist per qualificare il fornitore

Il controllo non finisce sul singolo file. CISA mette a disposizione un modello di valutazione della supply chain pensato per le PMI, applicabile all’acquisto di hardware, software e servizi. Per workstation e mini PC trasformerei quel modello in domande brevi da fare prima dell’ordine:

Il vendor pubblica driver e firmware da un portale unico e riconoscibile?
Indica versione, data, modello compatibile e hash dei pacchetti?
Ritira davvero i file obsoleti o si limita a togliere i link?
Esiste un canale per gli avvisi di sicurezza e una cronologia delle correzioni?
La reinstallazione può partire da un’immagine Microsoft pulita, senza utility obbligatorie?
Il supporto sa identificare un pacchetto tramite hash e risponde con una procedura verificabile?

Il prezzo del dispositivo va letto insieme a questo costo operativo. Un PC economico che richiede driver trovati su pagine vecchie, pacchetti senza metadati e supporto poco tracciabile sposta il risparmio dall’acquisto alla manutenzione. Per una PMI con dieci postazioni basta un singolo incidente per cancellare la differenza.

La mia take: il dominio ufficiale è solo il primo controllo

Il consiglio “scarica solo dal sito ufficiale” è necessario, ma incompleto. Il caso GEEKOM nasce proprio da una risorsa associata al supporto del produttore e rimasta accessibile fuori dalla navigazione corrente. Search engine e assistenti AI possono riportare in superficie pagine che l’azienda considera superate ma non ha davvero ritirato.

Per questo il confine di fiducia non deve coincidere con il dominio. Deve arrivare fino al singolo artefatto: percorso corrente, versione, hash, firma, scansione, pilota e log. È un gate leggero, applicabile anche senza SOC o team enterprise. Richiede qualche minuto prima dell’installazione e restituisce una cosa che manca quasi sempre quando scoppia il problema: sapere quale file è entrato, dove e con quale approvazione.

Procedura operativa in dieci passaggi

Apri il supporto partendo dalla home del vendor, non dal risultato di ricerca.
Verifica modello hardware, sistema operativo, versione e data del pacchetto.
Scarica in una cartella di staging e non eseguire il file.
Calcola lo SHA-256 e confrontalo con quello pubblicato, se disponibile.
Estrai il pacchetto e controlla firme e publisher dei componenti eseguibili.
Esegui la scansione locale; usa servizi esterni solo secondo policy.
Installa su un dispositivo pilota ripristinabile e senza dati critici.
Osserva eventi, servizi, rete, sicurezza e versione effettivamente attiva.
Distribuisci a gruppi con soglia di stop e rollback già preparato.
Registra hash, origine, dispositivi, operatore ed esito nel ticket.