Persistenza via DLL Globale: AppInit DLLs (T1546.010)

Per simulare questa tecnica in ambiente lab è sufficiente un sistema Windows 7 o un Windows 10 con Secure Boot disabilitato. L'obiettivo dell'esercizio è dimostrare come una singola modifica al registro possa trasformare ogni processo GUI in un vettore di esecuzione. Ti servono privilegi amministrativi locali — senza quelli, la chiave HKLM non è scrivibile.

Inizia preparando una DLL di test. Con msfvenom (open source, parte di Metasploit Framework) puoi generare un payload che si limiti a scrivere un marker su disco, senza comportamento distruttivo:

msfvenom -p windows/exec CMD="cmd.exe /c echo APPINIT_TEST > C:\Windows\Temp\appinit_proof.txt" -f dll -o C:\test\appinit_test.dll

In un contesto più controllato, puoi compilare una DLL minima in C che scrive un log in DLL_PROCESS_ATTACH. L'importante è che la DLL non faccia crashare i processi ospite — un errore frequente nei lab è generare payload che terminano il processo, causando instabilità a cascata.

Per impostare la persistenza, usa questi due comandi da un prompt amministrativo:

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t REG_SZ /d "C:\test\appinit_test.dll" /f

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs /t REG_DWORD /d 1 /f

Il primo comando registra il percorso della DLL, il secondo attiva il meccanismo di caricamento. Da questo momento, apri un qualunque programma che importa user32.dll — Notepad, Calculator, Explorer — e la tua DLL verrà caricata nel suo spazio di indirizzamento.

Per verificare l'avvenuto caricamento, Process Explorer (gratuito, Sysinternals) è lo strumento ideale: apri il processo target, vai alla vista DLL e cerca la tua libreria nella lista. In alternativa, con PowerShell:

Get-Process | ForEach-Object { $.Modules } | Where-Object { $.FileName -like "appinit_test" }

Per l'equivalente WoW6432Node (processi a 32 bit su OS a 64 bit), ripeti la stessa operazione sulla chiave:

reg add "HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs /t REG_SZ /d "C:\test\appinit_test.dll" /f

Al termine del test, rimuovi le chiavi e riavvia. Il framework Atomic Red Team (open source) include un test atomico per T1546.010 che automatizza setup e cleanup — usalo se vuoi integrare la simulazione in una pipeline di validazione continua.

La detection di questa tecnica si articola in due momenti ben distinti: la modifica del registro e il successivo caricamento anomalo di DLL. La correlazione tra i due eventi è ciò che trasforma un segnale debole in un alert ad alta confidenza.

La sorgente log primaria è Sysmon (open source, Sysinternals). L'EventCode 13 (RegistryEvent – SetValue) cattura ogni scrittura sulle chiavi di registro. La regola deve monitorare i path \Microsoft\Windows NT\CurrentVersion\Windows con target value AppInit_DLLs oppure LoadAppInit_DLLs. In un ambiente enterprise sano, queste chiavi non vengono mai modificate dopo l'installazione del sistema operativo — qualsiasi scrittura è sospetta per definizione.

Il secondo pilastro è l'EventCode 7 di Sysmon (Image Loaded), che registra ogni DLL caricata da un processo. Qui la sfida è il volume: su un endpoint medio, il caricamento di DLL avviene centinaia di volte al minuto. Il trucco è filtrare per DLL non firmate digitalmente o firmate da entità sconosciute, caricate da percorsi inusuali come %APPDATA%, %TEMP% o directory utente. Il malware T9000 ad esempio usava %APPDATA%\Intel\ResN32.dll, mentre Cherry Picker piazzava la propria pserver32.dll senza un percorso completo, affidandosi all'ordine di ricerca DLL del sistema.

Per il tuning dei falsi positivi, la strategia raccomandata nella detection DET0557 prevede quattro assi di calibrazione:

• ImagePathWhitelist: mantieni una lista dei percorsi DLL legittimi già presenti nel baseline del tuo ambiente. Alcune applicazioni enterprise legacy usano AppInit_DLLs — poche, ma esistono.
• UserContext: una modifica effettuata da un account standard è molto più sospetta della stessa operazione eseguita da un account di deploy durante una finestra di manutenzione.
• TimeWindow: correla la modifica del registro con il primo caricamento anomalo di DLL entro un intervallo configurabile (30-60 minuti è un buon punto di partenza).
• DLLSignatureStatus: assegna severity elevata alle DLL non firmate e media a quelle con firma valida ma non presente nella tua trust list.

Come controllo preventivo, le mitigazioni indicano l'adozione di Windows Defender Application Control (WDAC) o AppLocker (inclusi in Windows Enterprise) per bloccare l'esecuzione di DLL non autorizzate. Una policy WDAC che consenta solo DLL firmate da publisher noti neutralizza completamente questa tecnica. In alternativa, una Software Restriction Policy che impedisca l'esecuzione di binari da %APPDATA% e %TEMP% copre i pattern di deployment più comuni osservati in the wild.

Il consiglio architetturale più efficace resta l'abilitazione di Secure Boot e l'aggiornamento a Windows 8 o successivi, che disabilita AppInit_DLLs a livello kernel — eliminando il vettore alla radice.

L'analisi forense di un abuso di AppInit DLLs segue una catena di artefatti ben definita che parte dal registro e si estende negli spazi di memoria di decine di processi. Il punto di ingresso è sempre lo stesso: le chiavi di registro sotto HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows.

Il primo passo è estrarre il valore corrente e la cronologia delle modifiche di queste chiavi. Con Registry Explorer (open source, Eric Zimmerman) o RegRipper (open source), analizza l'hive SOFTWARE offline. Ogni chiave di registro in Windows conserva un timestamp di ultima modifica — il cosiddetto LastWriteTime — che ti fornisce il momento esatto dell'impianto della persistenza. Confronta questo timestamp con il momento della compromissione iniziale per misurare il dwell time tra accesso e stabilizzazione.

reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v AppInit_DLLs

reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows" /v LoadAppInit_DLLs

Questi comandi ti danno lo stato corrente, ma per la timeline forense è essenziale lavorare sull'hive raw. Cerca anche la chiave WoW6432Node: il malware Ramsay si inseriva nello spazio di indirizzamento di altre applicazioni tramite questo meccanismo, potenzialmente sfruttando entrambe le chiavi per coprire processi sia a 32 che a 64 bit.

Il secondo artefatto chiave è la DLL stessa. Nel caso di T9000, il file ResN32.dll veniva depositato in %APPDATA%\Intel\ — un percorso che simula una directory legittima Intel. Recupera la DLL, calcolane l'hash e verifica il timestamp di compilazione nel PE header con PEStudio (gratuito) o pestudio-cli. Confronta il TimeDateStamp della compilazione con il LastWriteTime della chiave di registro e con i timestamp MAC del file su disco (creazione, modifica, accesso da $MFT).

Nei log Sysmon, ricostruisci la sequenza temporale cercando in ordine:

1. EventCode 13 — la scrittura del valore AppInit_DLLs nel registro, con il processo responsabile nel campo Image
2. EventCode 11 — la creazione del file DLL su disco (FileCreate), con hash e percorso
3. EventCode 7 — il primo caricamento della DLL da parte di un processo che importa user32.dll

Per Cherry Picker, la DLL pserver32.dll veniva registrata senza percorso assoluto, il che implica che il sistema operativo la cercava nell'ordine standard di ricerca DLL. In fase forense, questo significa che devi controllare non solo la directory specificata, ma anche C:\Windows\System32, C:\Windows\SysWOW64 e la directory corrente dei processi che l'hanno caricata.

Infine, analizza i dump di memoria con Volatility 3 (open source). Il plugin windows.dlllist mostra le DLL caricate per ogni processo, mentre windows.registry.hivelist seguito da windows.registry.printkey ti permette di leggere le chiavi AppInit direttamente dalla memoria — utile quando l'attaccante ha ripulito il registro su disco ma il sistema non è stato ancora riavviato.

L'utilizzo di AppInit DLLs come vettore di persistenza racconta una storia chiara sulle priorità operative degli attori coinvolti: massima copertura con minimo sforzo, a costo di una bassa discrezione. Caricare una DLL in ogni processo GUI è un approccio rumoroso, che suggerisce scenari in cui l'attore valuta la resilienza della persistenza più importante della furtività.

APT39 (G0087), gruppo attribuito ad attività di cyber-spionaggio, ha utilizzato malware specifico per impostare LoadAppInit_DLLs nella chiave di registro SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows. Questo gruppo è noto per campagne focalizzate sulla raccolta di informazioni personali e di viaggio, e la scelta di AppInit DLLs come meccanismo di persistenza suggerisce un'operazione su target con sistemi operativi datati o configurazioni UEFI permissive — coerente con ambienti enterprise in settori meno maturi nella postura di sicurezza.

Sul versante software, emergono tre famiglie con approcci distinti alla stessa tecnica. T9000 (S0098) rappresenta l'implementazione più sofisticata: verifica che la vittima soddisfi determinati criteri prima di attivare il meccanismo, depositando ResN32.dll in un percorso che mima una directory Intel legittima. Questa condizionalità indica un operatore attento alla selettività dei target. Cherry Picker (S0107), orientato al furto di dati di pagamento, adotta un approccio più diretto registrando pserver32.dll senza percorso assoluto — una scelta che sacrifica il controllo sulla risoluzione del path in favore della semplicità di deployment. Ramsay (S0458), progettato per operare in ambienti air-gapped, usa AppInit DLLs per inserirsi nello spazio di indirizzamento di altre applicazioni, coerente con la sua necessità di intercettare dati da processi di interesse senza disporre di comunicazioni di rete.

Il pattern che emerge è geograficamente e settorialmente variegato, ma tecnicamente convergente: tutti e tre i malware operano sulla stessa coppia di valori di registro, con variazioni minime nel percorso della DLL. Per un analista TI, questo significa che un singolo indicatore di compromissione a livello di registro — la modifica di AppInit_DLLs o LoadAppInit_DLLs — copre l'intera superficie della tecnica.

Dal punto di vista predittivo, la tecnica è in declino per gli ambienti moderni con Secure Boot. Gli attori che continuano a usarla probabilmente operano contro target con sistemi Windows 7 o precedenti, oppure con macchine virtuali dove Secure Boot non è abilitato di default. In contesti di threat modeling, la presenza di questa tecnica nel TTP profile di un avversario è un indicatore utile per stimare il livello di modernità degli ambienti che l'attore è abituato a compromettere.

Framework MITRE ATT&CK v16 — T1546.010 (Event Triggered Execution: AppInit DLLs), TA0003, TA0004. Gruppi: G0087. Software: S0098, S0107, S0458. Mitigazioni: M1038, M1051. Detection: DET0557, AN1536. Integrato con conoscenza professionale per tool e procedure operative.