Sovvertire i Controlli di Fiducia: Subvert Trust Controls (T1553)
La tecnica T1553 - Subvert Trust Controls raccoglie l'insieme di manipolazioni che un attaccante mette in atto per aggirare i meccanismi con cui sistemi operativi e prodotti di sicurezza stabiliscono la fiducia in un file, un certificato o un sito web. Rientra nella tattica TA0005 (Defense Evasion) perché il suo scopo non è ottenere accesso o persistenza in senso stretto, ma disinnescare gli avvisi che dovrebbero mettere in allarme utenti e strumenti difensivi.
Gli esempi sono concreti e quotidiani: un binario che gira senza prompt perché firmato con un certificato valido, un installer che non attiva SmartScreen perché privo del flag Mark-of-the-Web, un sito HTTPS che non genera warning perché la CA compromessa è considerata trusted. L'avversario agisce su questi anelli — root store, provider SIP, attributi estesi del filesystem, chiavi di registro dei trust provider — per far apparire legittimo ciò che non lo è.
L'impatto operativo è significativo: neutralizzare i controlli di fiducia significa vanificare investimenti in code signing, application control e reputation-based detection. La matrice MITRE censisce 1 gruppo APT documentato (Axiom), 5 mitigazioni ufficiali e una singola analytic multi-piattaforma (DET0452) che copre Windows, Linux e macOS. La superficie difensiva è ampia proprio perché ogni OS implementa i trust controls in modo diverso, richiedendo strategie di detection specifiche.
Sul fronte offensivo, T1553 si simula lavorando sui tre sistemi operativi con approcci distinti. Su Windows il primo esercizio riguarda il Mark-of-the-Web: quando un file viene scaricato via browser, viene creato uno stream NTFS alternativo Zone.Identifier che segnala l'origine Internet. Rimuoverlo è banale con PowerShell tramite Unblock-File -Path .\payload.exe, oppure eliminando lo stream con Remove-Item -Path .\payload.exe:Zone.Identifier. Un red team può verificare quali canali di ingresso (SMB, WebDAV, container ISO) non applicano MOTW, storicamente un vettore usato per bypassare SmartScreen.
Un secondo scenario è la manipolazione dei trust provider SIP (Subject Interface Package): le chiavi HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg controllano quali DLL validano le firme Authenticode. Riscriverne il puntatore su una DLL controllata dall'attaccante consente di far risultare valido qualsiasi binario. Il tool di riferimento per studiare questi hijack è SigThief (open source), che permette di prendere una firma valida da un binario legittimo e appenderla a un payload non firmato per test di robustezza dei controlli.
Per la generazione di certificati di code signing autofirmati in laboratorio si usa il cmdlet New-SelfSignedCertificate con parametro -Type CodeSigningCert, seguito da Set-AuthenticodeSignature per firmare l'artefatto. Utile per verificare quali EDR distinguono firme trusted da firme valide-ma-non-riconosciute.
Su macOS la simulazione ruota attorno a Gatekeeper e all'attributo esteso com.apple.quarantine. Il comando xattr -d com.apple.quarantine /path/to/App.app rimuove il flag che triggera il prompt di Gatekeeper, mentre spctl --add e security add-trusted-cert permettono di iniettare CA arbitrarie nel keychain di sistema. Un red team deve testare se l'EDR intercetta queste chiamate o solo l'esecuzione successiva.
Su Linux l'azione tipica è l'inserimento di root CA in /usr/local/share/ca-certificates/ seguito da update-ca-certificates, utile per abilitare intercettazioni TLS successive. Framework come Atomic Red Team (open source) contengono test pronti per T1553 in tutte le sotto-tecniche, ideali per validare la copertura di detection senza sviluppare payload custom. La regola cardine per il laboratorio: eseguire sempre in VM isolate senza connettività con l'ambiente enterprise, perché la modifica dei trust store può persistere in modo pericoloso.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo