Pacchetti di Autenticazione LSA: Authentication Package (T1547.002)
La tecnica T1547.002 - Authentication Package sfrutta un meccanismo legittimo di Windows per ottenere persistenza (TA0003) e potenzialmente privilege escalation (TA0004) fino al livello SYSTEM. Il Local Security Authority Subsystem Service, meglio noto come LSASS, carica all'avvio del sistema una serie di DLL registrate come authentication package, componenti pensati per supportare protocolli di logon e autenticazione multipli come Kerberos, NTLM e MSV1_0.
L'abuso è concettualmente semplice: aggiungendo un riferimento a un binario arbitrario nella chiave di registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages, l'attaccante ottiene che quel codice venga eseguito da LSASS a ogni boot, all'interno di un processo altamente privilegiato e critico per la sicurezza dell'host. Il risultato è una persistenza estremamente stealth, che sopravvive a reboot e cambi di credenziali, e che eredita il contesto di sicurezza di uno dei processi più sensibili del sistema operativo.
Si tratta di una tecnica documentata da anni ma tuttora rilevante: il malware Flame (S0143) l'ha utilizzata come vettore di persistenza in una delle campagne di cyber-spionaggio più sofisticate mai analizzate. La mitigazione principale, disponibile da Windows 8.1 in poi, consiste nell'attivazione di LSA Protection tramite PPL, che impone la firma Microsoft su tutte le DLL caricate da LSASS e riduce drasticamente la superficie di attacco.
Per riprodurre la tecnica in un laboratorio controllato serve una macchina Windows con privilegi amministrativi locali, requisito indispensabile poiché la scrittura in HKLM\SYSTEM\CurrentControlSet\Control\Lsa è protetta. L'obiettivo è dimostrare che una DLL non firmata possa essere caricata da LSASS al boot come authentication package.
Il primo passo è preparare la DLL payload. In un contesto red team si può usare una semplice DLL scritta in C che esporti la funzione SpLsaModeInitialize, richiesta dall'API SSPI per essere riconosciuta come authentication package valido. Framework come Metasploit (open source) o Cobalt Strike (a pagamento) permettono di generare shellcode DLL adatti, ma per un esercizio didattico è più istruttivo compilare una DLL minimale con MinGW o Visual Studio che scriva su file un marker all'avvio, così da confermare l'esecuzione senza rischi.
La DLL va posizionata in *C:\Windows\System32* (o percorso analogo raggiungibile da LSASS) con un nome breve e senza estensione nel registro. La modifica del registro avviene con:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "Authentication Packages" /t REG_MULTI_SZ /d "msv1_0\0evilpkg" /f
Attenzione: il valore è di tipo REG_MULTI_SZ, quindi va preservata la voce originale msv1_0 per non compromettere l'autenticazione locale. Un errore qui porta a un sistema non avviabile. Dopo il reboot, LSASS caricherà la DLL aggiuntiva e sarà osservabile nella lista dei moduli con Process Explorer (gratuito, Sysinternals) o via listdlls.exe -d lsass.exe.
Per un esercizio più realistico, la catena può essere estesa: initial access via phishing, escalation locale a SYSTEM tramite tecniche note, drop della DLL e modifica del registro come step di persistenza post-exploitation. Il framework Atomic Red Team (open source) include test specifici per T1547.002 che permettono di validare rapidamente la detection senza scrivere codice custom.
Per chi vuole studiare l'interfaccia interna, i tool Mimikatz (open source) e pypykatz (open source) mostrano come LSASS espone gli authentication package caricati e come interagire con SSPI. In lab isolato, disabilitare temporaneamente LSA Protection è necessario perché sistemi moderni con RunAsPPL attivo rifiuteranno il caricamento di DLL non firmate Microsoft, che è esattamente il comportamento difensivo che vogliamo poi verificare.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo