Cos'è il DLL hijacking e perché il tuo nuovo plugin AI potrebbe essere il modo più semplice per entrare

Ho passato molto tempo quest’anno a osservare come le organizzazioni stanno integrando AI in strumenti che non sono mai stati progettati per gestirla. La maggior parte di questo rischio viene discussa in termini di esposizione dei dati o comportamento del modello. Meno attenzione viene data a qualcosa di più basilare: il processo di installazione stesso. Quando un team aggiunge un plugin AI a un’applicazione desktop legacy, spesso aggiunge un nuovo eseguibile, un nuovo set di dipendenze e una nuova serie di cartelle che Windows cercherà quando quell’applicazione cerca di caricare una DLL. Questa è una configurazione familiare a chiunque abbia seguito il DLL hijacking negli anni, e sta diventando sempre più comune.

Cos'è il DLL hijacking

Le applicazioni Windows non caricano sempre le loro DLL da una posizione fissa e attendibile. Quando un'app richiede una DLL per nome anziché per percorso completo, Windows cerca in un ordine definito di directory per trovarla. Se un attaccante può posizionare una DLL dannosa con il nome corretto in una posizione precedente in quell'ordine di ricerca, l'applicazione carica il codice dell'attaccante invece della libreria legittima, e lo fa con i privilegi che l'applicazione ha già.

Questa non è una tecnica nuova. È una vulnerabilità documentata da anni e continua a funzionare perché molte applicazioni desktop, soprattutto quelle più vecchie o mal progettate, caricano ancora le DLL per nome anziché per percorso completo. Ciò che è cambiato è la superficie di attacco. Ogni plugin, componente aggiuntivo o estensione basata su IA installata in un'app legacy è una nuova opportunità per una cartella poco controllata, una dipendenza non firmata o una directory scrivibile nel percorso di ricerca.

Esempio di hijacking DLL

Immagina un team di ingegneri che utilizza un'applicazione CAD attiva da un decennio. IT aggiunge un plugin AI che offre agli utenti uno strato intelligente di ricerca e sintesi sopra i loro disegni. Come molti software in questa categoria, l'app CAD carica una delle sue DLL di supporto per nome anziché per percorso completo, una scelta progettuale che nessuno ha mai messo in discussione perché non ha mai causato problemi visibili.

Un attaccante con anche solo un accesso limitato a quella macchina, tramite phishing, un account compromesso o un altro punto d’appoggio, non deve violare il plugin AI stesso. Deve solo inserire un DLL con lo stesso nome file in una cartella che si trova prima nell’ordine di ricerca dell’app. La prossima volta che un utente avvia l’app, carica il DLL dell’attaccante, e il codice dannoso viene eseguito con gli stessi privilegi dell’applicazione CAD. Non serve sfruttare il plugin AI. Il plugin ha semplicemente fornito all’attaccante una nuova cartella su cui lavorare.

Come rilevare il dirottamento DLL

La rilevazione di solito consiste nell’osservare comportamenti che non corrispondono a ciò che dovrebbe fare una DLL legittima:

• Applicazioni che caricano DLL per nome da directory insolite o scrivibili dall’utente invece di un percorso completo e attendibile
• DLL non firmate avviate tramite utility come rundll32.exe, un modello comune di hijack
• Monitoraggio dell'integrità dei file segnalazione di modifiche alle DLL che non dovrebbero cambiare tra i cicli di patch
• Log di Endpoint che mostrano un processo padre legittimo seguito da un caricamento DLL imprevisto o non firmato

Un altro modo è controllare l'integrità di qualsiasi DLL nel percorso di ricerca (in realtà l'integrità di tutti i file) confrontando i loro valori hash con una fonte nota e affidabile.

Niente di tutto ciò è esotico. È la stessa disciplina che i team di sicurezza applicano già all'integrità dei file e al monitoraggio dei processi, rivolta specificamente alle cartelle dove i plugin di terze parti e le app legacy tendono a introdurre comportamenti deboli nell'ordine di caricamento.

Come prevenire il dirottamento DLL

La prevenzione rientra generalmente in due categorie: correggere le applicazioni e controllare cosa è consentito eseguire sull'endpoint.

Correggere l'applicazione significa utilizzare percorsi completamente qualificati per il caricamento delle DLL, restringere i permessi delle cartelle in modo che gli utenti standard non possano scrivere nelle directory che l'app cerca e mantenere il software del fornitore aggiornato. Questa è la soluzione corretta a lungo termine, ma dipende da ogni fornitore che faccia il lavoro, e molte delle applicazioni più esposte a questo problema sono proprio quelle meno propense a essere aggiornate rapidamente.

Controllare l'endpoint significa non dover aspettare il fornitore. PolicyPakDLL Hijack Protection di PolicyPak, parte di Least Privilege Manager, funziona in tre modalità: audit, che registra i caricamenti di DLL rischiosi senza bloccarli per consentire ai team di valutare l'esposizione; safe elevated, che blocca il caricamento di DLL rischiosi per i processi elevati; e anti-hijack, che estende questo blocco ai processi normali in esecuzione da posizioni protette come Program Files. Blocca direttamente i due schemi di hijack più comuni: un'applicazione che carica una DLL con un nome non qualificato invece del percorso completo, e una DLL non firmata avviata tramite un'utilità come rundll32.exe. Quando una DLL legittima viene bloccata per errore, gli amministratori possono consentirla tramite percorso file, firma digitale o hash del file senza disattivare completamente la protezione.

Se il tuo team sta implementando capacità di IA in applicazioni precedenti a questa conversazione, il dirottamento DLL merita un posto nel registro dei rischi, non come ipotesi, ma come conseguenza a breve termine di come vengono installati quei plugin.