Manomissione Firma Codice: Code Signing Policy Modification (T1553.006)

In un red team engagement, la simulazione di T1553.006 richiede un laboratorio isolato con snapshot ripristinabili, perché le modifiche impattano il boot del sistema. Le operazioni presuppongono privilegi amministrativi già acquisiti tramite altre tecniche di privilege escalation.

Su Windows, l'approccio più diretto è l'abilitazione del test signing mode. Il comando canonico è:

bcdedit.exe /set testsigning on

seguito da reboot. Una volta attivo, il sistema accetta driver firmati con certificati self-signed generati ad esempio tramite MakeCert del Windows SDK (gratuito) o New-SelfSignedCertificate in PowerShell. Per nascondere il watermark Test Mode si può ricorrere a tool come Universal Watermark Disabler (gratuito) o modificare le risorse di user32.dll — operazione rumorosa e sconsigliata in scenari stealth.

L'approccio più sofisticato, coerente con quanto documentato per Turla, è la modifica in-memory della variabile g_CiOptions nel modulo CI.dll del kernel. Questo richiede accesso kernel-mode, tipicamente ottenuto tramite BYOVD (Bring Your Own Vulnerable Driver): si carica un driver firmato ma vulnerabile (esempi pubblici includono RTCore64.sys, gdrv.sys, dbutil_2_3.sys, tutti censiti nel progetto LOLDrivers — open source), si sfrutta la primitiva di read/write arbitrario per azzerare g_CiOptions e disabilitare DSE runtime senza reboot né watermark. Tool didattici come KDMapper (open source) e Kernel Driver Utility (open source) implementano questa catena e sono utili per validare le detection in lab.

Su macOS la simulazione richiede reboot in Recovery Mode (Command+R all'avvio) ed esecuzione dal Terminal di:

csrutil disable

seguito da reboot normale. Lo stato è verificabile con csrutil status. Su Apple Silicon la procedura è diversa e passa per la modalità 1TR (One True Recovery) con csrutil disable preceduto dall'abbassamento della security policy tramite bputil.

Per la fase di reporting, è utile documentare l'impatto: caricamento di un driver di test (es. un semplice driver echo compilato con WDK) prima e dopo la modifica, dimostrando che senza test signing il caricamento fallisce con errore STATUS_INVALID_IMAGE_HASH. Framework come Atomic Red Team (open source) includono atomici specifici per T1553.006 utili per validare le regole di detection in modo ripetibile e sicuro.

La detection di T1553.006 si fonda su tre pilastri: monitoraggio di eseguibili amministrativi ad alto rischio, tracciamento di modifiche registry mirate e correlazione temporale con esecuzioni successive di codice non firmato.

Su Windows la telemetria chiave arriva da Sysmon (open source) e dal Security log. L'EventCode 1 di Sysmon intercetta esecuzioni di bcdedit.exe con parametri come testsigning, nointegritychecks o loadoptions DISABLE_INTEGRITY_CHECKS. Una regola efficace filtra la command line contenente testsigning AND on, con soglia bassa perché l'uso legittimo è raro fuori dai contesti di sviluppo driver. L'EventCode 13 di Sysmon copre le modifiche a chiavi come HKLM\SYSTEM\CurrentControlSet\Control\CI\Config e valori correlati alla policy di code integrity.

Dal Security log di Windows, l'EventCode 4688 (Process Creation, richiede audit policy abilitata) e 4657 (Registry Value Modified, richiede SACL sulle chiavi target) forniscono coverage nativa senza dipendenze. È fondamentale abilitare l'auditing con auditpol /set /subcategory:"Registry" /success:enable /failure:enable come indicato dalla mitigazione M1024.

Un indicatore ad altissima confidenza è il caricamento di driver non firmati o firmati con certificati self-signed: Sysmon EventCode 6 (Driver Loaded) riporta signature status e signer. Correlare eventi con Signed=false o signer non presenti in una allowlist enterprise consente di rilevare l'effetto della policy modification anche quando la modifica stessa è avvenuta via kernel memory patching. Analogamente, il caricamento di driver noti come vulnerabili (dataset LOLDrivers, open source, aggiornato dalla community) è un red flag per scenari BYOVD.

Su macOS la fonte primaria è l'Unified Log interrogabile via log show --predicate 'process == "csrutil"' --last 24h. L'esecuzione di csrutil disable durante il normale boot fallisce ed è essa stessa un IOC; l'attivazione effettiva richiede Recovery Mode, quindi eventi di reboot inattesi seguiti da uno stato SIP alterato sono altamente sospetti. Lo stato è ricavabile programmaticamente via csrutil status o interrogando nvram csr-active-config.

I falsi positivi principali riguardano workstation di sviluppatori driver, sistemi di build e ambienti di QA. Una tuning strategy efficace prevede allowlist per hostname e per utente (tipicamente account tecnici dedicati), con soglia alta per il resto del parco. La finestra di correlazione consigliata tra modifica policy ed esecuzione di binario/driver non firmato è di 24-72 ore, coprendo anche scenari con reboot pianificato ritardato.

L'analisi forense di T1553.006 si articola su artefatti persistenti nel registry, log di boot, evidenze del filesystem e — nei casi kernel-level — memoria volatile.

Su Windows il primo elemento da acquisire è la BCD (Boot Configuration Data), esportabile con bcdedit /enum /v su sistema live o parsabile offline dall'hive \Boot\BCD con tool come BCD-Parser o Registry Explorer (freemium, di Eric Zimmerman). I flag rilevanti sono testsigning, nointegritychecks e loadoptions. Anche dopo che l'attaccante ha ripristinato testsigning off, il timestamp dell'ultima modifica dell'hive fornisce un pivot temporale.

Nel registry principale, le chiavi HKLM\SYSTEM\CurrentControlSet\Control\CI\Config e HKLM\SYSTEM\CurrentControlSet\Control\CI\Protected contengono la configurazione di Code Integrity. RegRipper (open source) e Registry Explorer (freemium) permettono estrazione strutturata. I LastWrite timestamp delle chiavi vanno correlati con la timeline generale del caso.

Gli Event Log di interesse risiedono in %SystemRoot%\System32\winevt\Logs\. Il canale Microsoft-Windows-CodeIntegrity/Operational registra eventi EventID 3033 (blocco di driver non firmato) e 3077 (violazione policy): la loro assenza in un periodo in cui erano attesi è essa stessa indicatore. Il System.evtx traccia i reboot (EventID 6005/6006) utili a ricostruire il momento in cui una modifica BCD è divenuta effettiva.

Per scenari kernel-memory patching (Turla, Pandora via CVE-2017-15303), l'analisi richiede acquisizione di memoria con WinPmem (open source) o Magnet RAM Capture (gratuito) e successiva analisi con Volatility 3 (open source). Il plugin windows.modules elenca i driver caricati, mentre l'ispezione del modulo CI.dll mappato in kernel space consente di verificare il valore di g_CiOptions: valori diversi da 0x6 (default con DSE attivo) su Windows 10/11 x64 sono indicatori diretti di tampering.

Su macOS l'artefatto centrale è la variabile NVRAM csr-active-config, leggibile con nvram csr-active-config: valori diversi da quelli di default indicano SIP alterato. L'Unified Log è archiviato in /var/db/diagnostics/ ed estraibile con log collect. Il file /System/Library/Sandbox/rootless.conf elenca i path protetti da SIP.

La timeline consigliata per casi BlackEnergy o Hikit correla: modifica registry CI → reboot → primo caricamento driver rootkit → attività di persistence. Plaso/log2timeline (open source) permette di fondere event log, registry timestamps e MFT in un'unica timeline navigabile con Timeline Explorer (freemium).

Il panorama degli attori che sfruttano T1553.006 è ristretto ma qualitativamente rilevante: si tratta di gruppi con capacità kernel-mode mature e obiettivi che richiedono persistenza profonda e stealth.

Turla (G0010), attribuito da più vendor a servizi di intelligence russi, rappresenta il caso di scuola per la manipolazione runtime della policy. Il gruppo ha modificato variabili in kernel memory per disattivare DSE dopo aver ottenuto privilegi kernel-mode tramite exploit. Questa capacità è coerente con l'arsenale storico di Turla, noto per rootkit come Uroburos/Snake e per l'uso di driver firmati vulnerabili come vettore di accesso al kernel. La modifica in-memory è particolarmente insidiosa perché non lascia tracce persistenti nel BCD e sopravvive solo fino al reboot successivo, complicando la detection ex post.

APT39 (G0087), cluster associato a operazioni di intelligence iraniana con focus su telecomunicazioni e viaggi, ha adottato un approccio complementare: malware sviluppato dal gruppo disabilita il feature RequireSigned per consentire il caricamento di DLL non firmate su Windows. Il target è quindi il codice user-mode, con implicazioni sulla injection e sul side-loading di componenti malevoli in processi legittimi.

Sul fronte malware, BlackEnergy (S0089) — storicamente collegato a operazioni contro infrastrutture critiche ucraine — abilita TESTSIGNING via BCD per caricare il proprio driver kernel-mode, secondo il pattern più tradizionale con reboot e watermark potenzialmente visibile. Hikit (S0009), rootkit associato ad attori APT cinesi, manomette molteplici chiavi registry per disabilitare la verifica delle firme driver prima del caricamento della componente rootkit. Pandora (S0664) adotta l'approccio BYOVD sfruttando CVE-2017-15303 per disattivare DSE e caricare il proprio driver, dimostrando come vulnerabilità note in driver firmati restino armi valide anni dopo la disclosure.

Il pattern trasversale è chiaro: T1553.006 non è tecnica di massa ma enabler per operazioni high-end dove la persistenza kernel-level è requisito. Geograficamente coprono i principali cluster di threat actor statuali (Russia, Cina, Iran). Il trend osservabile — supportato dalla crescita del dataset LOLDrivers — è lo spostamento dalla modifica esplicita della policy (rumorosa, tracciabile) verso il BYOVD con patching in-memory (silenzioso, volatile). Per il threat intel officer questo implica prioritizzare l'intelligence su driver vulnerabili emergenti e monitorare vendor advisory per revoche di certificati Microsoft su driver compromessi.

MITRE ATT&CK T1553.006 (Code Signing Policy Modification), tattica TA0005. Gruppi G0010 (Turla), G0087 (APT39). Software S0009 (Hikit), S0089 (BlackEnergy), S0664 (Pandora). Mitigazioni M1024, M1026, M1046. Detection DET0523 (analitiche AN1446 Windows, AN1447 macOS). Framework MITRE D3FEND per artefatti difensivi. Progetto LOLDrivers per catalogo driver vulnerabili. Contenuti su tool operativi (Sysmon, Volatility, Plaso, Atomic Red Team, KDMapper, WinPmem) derivano da conoscenza professionale di cybersecurity basata su documentazione ufficiale e repository pubblici dei rispettivi progetti.