Dirottamento SIP e Trust Provider: SIP and Trust Provider Hijacking (T1553.003)
La tecnica T1553.003 appartiene alla tattica TA0005 (Defense Evasion) e rappresenta una delle manipolazioni più insidiose dell'infrastruttura di validazione delle firme digitali di Windows. L'attaccante altera i componenti Subject Interface Package (SIP) o i trust provider per ingannare l'API WinVerifyTrust, che coordina la validazione crittografica dei file firmati tramite Authenticode.
L'architettura di Windows delega ai SIP l'astrazione tra formati di file eterogenei — eseguibili PE, script PowerShell, installer MSI, cataloghi — e le funzioni di verifica. Ogni SIP è identificato da un GUID e registrato sotto chiavi specifiche in HKLM\SOFTWARE\Microsoft\Cryptography. Modificando i valori Dll e FuncName che puntano alle funzioni CryptSIPDllGetSignedDataMsg, CryptSIPDllVerifyIndirectData o alla FinalPolicy del trust provider, l'avversario redirige il flusso di validazione verso DLL malevole che restituiscono sempre esito positivo.
L'impatto operativo è severo: AppLocker, Windows Defender Application Control (WDAC) e le policy di code signing possono essere aggirate silenziosamente, permettendo l'esecuzione di codice non firmato come se provenisse da Microsoft. La tecnica offre inoltre persistenza intrinseca, poiché ogni applicazione che invoca la validazione firme carica automaticamente i componenti compromessi. Rientra tipicamente nelle fasi post-exploitation della kill chain, dopo aver ottenuto privilegi SYSTEM necessari per scrivere nelle chiavi di registro protette.
In un esercizio red team autorizzato, la simulazione di T1553.003 richiede privilegi elevati e un ambiente isolato con snapshot ripristinabili, perché la manipolazione dei trust provider può compromettere la stabilità del sistema operativo.
Il primo passo consiste nell'enumerare i SIP registrati. Da PowerShell elevato:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData' | ForEach-Object { Get-ItemProperty $_.PSPath }
Questo restituisce i GUID dei SIP con le rispettive DLL e funzioni esportate. Per i PE il GUID rilevante è {C689AAB8-8E78-11D0-8C47-00C04FC295EE}, mentre per PowerShell è {603BCC1F-4B59-4E08-B724-D2C6297EF351}.
La proof-of-concept di riferimento nella community offensiva è SIP-Poc di Matt Graeber (open source, disponibile su GitHub nel repository matterpreter/SubvertTrust e nei materiali SpecterOps), che dimostra come compilare una DLL con funzioni esportate CryptSIPVerifyIndirectData che restituiscono sempre TRUE. Il flusso operativo è:
- Compilare la DLL malevola con Visual Studio o MinGW esportando la funzione con la stessa signature dell'originale.
- Copiare il binario in una directory protetta (evitando percorsi utente che verrebbero bloccati da WDAC in modalità enforcement).
- Riscrivere i valori Dll e FuncName nella chiave del SIP target con Set-ItemProperty.
- Validare l'hijack lanciando sigcheck.exe (Sysinternals, gratuito) contro un binario non firmato: dovrebbe risultare "Signed".
Un approccio più stealth, che evita di depositare file su disco, è redirigere FuncName verso una funzione già esportata da una DLL Microsoft legittima che restituisce TRUE o zero. Questa variante è documentata nel post "Subverting Trust in Windows" del 2018 e riduce la superficie di detection basata su nuovi file.
Per testare l'impatto sulle policy applicative, integra lo scenario con AtomicRedTeam (open source): il test T1553.003 include payload di modifica registro e binari di controllo firmati fittiziamente. L'obiettivo è verificare che il SOC rilevi non l'esecuzione del binario finale, ma la manipolazione delle chiavi crittografiche a monte.
Su ESXi e Linux la tecnica non è applicabile perché il modello Authenticode è specifico di Windows; l'equivalente concettuale su Linux sarebbe la manipolazione di dm-verity o del keyring del kernel, ma appartiene ad altre sottotecniche.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo