Firmare il Permesso di Passare: Code Signing Policy Modification (T1553.006)

La modifica delle policy di code signing è uno snodo cruciale in qualsiasi esercizio red team che preveda il caricamento di driver custom o rootkit in ambiente controllato. Il punto di partenza più immediato su Windows è l'abilitazione del Test Signing Mode tramite la BCD (Boot Configuration Data).

Con privilegi amministrativi, il comando classico è:

bcdedit.exe /set testsigning on

Dopo il riavvio, il sistema accetta driver firmati con certificati di test. Noterai un watermark nell'angolo inferiore destro del desktop che indica "Test Mode": un artefatto visivo che in un ingaggio reale l'avversario cercherebbe di rimuovere. Per verificare lo stato corrente della configurazione BCD senza riavviare, puoi ispezionare:

bcdedit /enum {current}

Il campo testsigning restituirà Yes se la modifica è attiva.

Un secondo vettore, più sofisticato e spesso preferito dagli attaccanti che non vogliono riavviare la macchina, prevede la manipolazione diretta della variabile g_CiOptions in memoria kernel. In laboratorio, questo si dimostra sfruttando un driver firmato ma vulnerabile — il cosiddetto pattern Bring Your Own Vulnerable Driver (BYOVD). Tool come KDU (Kernel Driver Utility, open source) automatizzano il processo: caricano un driver legittimo con vulnerabilità note di lettura/scrittura kernel e lo usano come ponte per azzerare i flag di ci.dll che impongono la verifica delle firme.

Su macOS, la simulazione passa per il Recovery Mode. Riavvia il sistema in modalità di recupero (Cmd+R all'avvio su Intel, tasto di accensione prolungato su Apple Silicon) e dal terminale esegui:

csrutil disable

Questo disabilita SIP, permettendo la modifica di directory protette e il caricamento di kernel extension non firmate. Per una disabilitazione parziale, più realistica in scenario red team:

csrutil enable --without kext

Lato Registry, è possibile replicare il comportamento documentato per il malware Hikit manipolando le chiavi relative alla verifica dei driver. Le chiavi coinvolte si trovano sotto il percorso HKLM\SYSTEM\CurrentControlSet\Control\CI e il valore UpgradedSystem può essere alterato con:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI" /v UpgradedSystem /t REG_DWORD /d 1 /f

Per documentare l'intera catena durante un engagement, registra ogni passaggio con Sysmon (open source) configurato per catturare eventi di modifica Registry (EventID 13) e creazione processi (EventID 1). Questo produce la telemetria necessaria al blue team per validare le proprie regole di detection.

La detection di questa tecnica poggia su due pilastri: il monitoraggio dei processi di sistema che modificano la configurazione di boot o il Registry, e la correlazione temporale tra queste modifiche e l'esecuzione successiva di binari non firmati.

Il primo alert da implementare riguarda l'esecuzione di bcdedit.exe con argomenti sospetti. Come indicato dalla detection AN1446, il log source primario è WinEventLog:Security, ma la telemetria più ricca arriva da Sysmon EventID 1 (Process Create). Una regola efficace filtra le invocazioni di bcdedit che contengono le stringhe testsigning, nointegritychecks o debug nella command line. Il tuning è fondamentale: in ambienti di sviluppo driver, bcdedit con testsigning può essere legittimo. Costruisci una whitelist basata su account e workstation autorizzate, e monitora le deviazioni.

Il secondo livello di detection è il monitoraggio Registry. Sysmon EventID 13 (Registry Value Set) cattura le modifiche alle chiavi sotto HKLM\SYSTEM\CurrentControlSet\Control\CI. Un alert su scritture a questa chiave da parte di processi diversi da Windows Update o installatori firmati è un indicatore ad alta fedeltà. La detection AN1446 suggerisce di personalizzare i percorsi Registry monitorati in base alla versione dell'OS — un consiglio pratico perché le chiavi cambiano leggermente tra Windows 10 e Windows 11.

Per macOS, la detection AN1447 si basa sui Unified Log e monitora l'esecuzione di csrutil disable. La correlazione qui è tra il comando csrutil e la successiva esecuzione di processi non firmati. Configurando un profilo di raccolta log con il predicato:

log show --predicate 'process == "csrutil"' --style syslog

ottieni la visibilità necessaria. Su endpoint gestiti con un EDR, cerca eventi di modifica dello stato SIP e correla con il caricamento di kernel extension non presenti nella baseline.

I falsi positivi più comuni provengono da tre sorgenti: sviluppatori che testano driver, aggiornamenti firmware che temporaneamente abilitano modalità di test, e amministratori che disabilitano SIP per installare tool di monitoraggio. La finestra di correlazione temporale tra la modifica della policy e l'esecuzione di codice non firmato — il parametro TimeWindow indicato nelle note di tuning — va calibrata: un intervallo di 5-15 minuti è un buon punto di partenza. Se la modifica della policy non è seguita da attività sospetta, l'alert può essere declassato a informativo.

Come controllo preventivo, la mitigazione Boot Integrity (M1046) suggerisce l'adozione di UEFI Secure Boot con attestazione TPM. Dove implementato, un cambio nel boot configuration viene rilevato dal TPM al successivo avvio, generando un evento misurabile e verificabile tramite remote attestation.

L'analisi forense di una modifica alle policy di code signing parte dalla BCD Store e arriva fino alla memoria kernel. Ogni strato lascia artefatti diversi, e la sfida è ricostruire la sequenza temporale completa.

Su Windows, il primo artefatto da esaminare è il BCD store stesso, tipicamente situato in \Boot\BCD sulla partizione EFI. Lo strumento bcdedit /enum all mostra la configurazione corrente, ma per un'analisi forense su immagine disco serve un parser offline. Il tool BCDEdit di Windows PE o ambienti forensi dedicati permettono di leggere il file BCD come un hive Registry. Cerca le voci testsigning, nointegritychecks e debug: se presenti e abilitate, hai la prova che la policy è stata alterata.

Il secondo artefatto critico è il Registry. Per il pattern usato da Hikit, le chiavi sotto HKLM\SYSTEM\CurrentControlSet\Control\CI sono il punto focale. Usa Registry Explorer (open source, di Eric Zimmerman) per analizzare l'hive SYSTEM offline e controllare i timestamp dell'ultima modifica (Last Write Time) su queste chiavi. Il timestamp ti dà il momento esatto della manipolazione e puoi correlarlo con altri eventi nella timeline.

Gli Event Log di Windows forniscono il contesto operativo. In Microsoft-Windows-CodeIntegrity/Operational (EventID 3001 e 3099) trovi gli eventi generati quando il sistema rileva un cambio nelle policy di integrità del codice o il caricamento di un driver non firmato. Questi log sono spesso trascurati ma contengono informazioni preziose sul nome del driver, il suo hash e il motivo del fallimento o dell'accettazione della verifica firma.

Per le tecniche che manipolano g_CiOptions in memoria kernel — come documentato per Turla — gli artefatti su disco sono più elusivi. La modifica avviene in RAM e non persiste al riavvio, il che rende essenziale la cattura di un memory dump. Con Volatility 3 (open source) puoi analizzare il dump cercando il valore corrente di g_CiOptions nel modulo ci.dll:

python3 vol.py -f memory.raw windows.modscan | grep -i ci.dll

Una volta localizzato il modulo, l'analisi del contenuto della variabile richiede il calcolo dell'offset e la lettura diretta dal dump. Se il valore è stato azzerato (0x0) anziché il default 0x6 (o 0x8 nelle versioni recenti), hai la conferma della disabilitazione DSE in memoria.

Su macOS, lo stato SIP è memorizzato nella NVRAM. Il comando nvram csr-active-config restituisce il valore corrente, ma su un'immagine forense puoi estrarlo dai file di configurazione NVRAM. Un valore diverso da 0x0 indica che SIP è stato parzialmente o totalmente disabilitato. Correla questo dato con i log unificati di macOS per trovare il timestamp esatto dell'esecuzione di csrutil.

La tecnica T1553.006 ha un'impronta operativa ristretta ma significativa. I due gruppi documentati rappresentano profili molto diversi per obiettivi e sofisticazione, il che suggerisce che la modifica delle policy di firma è un'esigenza trasversale per chiunque necessiti di operare a livello kernel.

APT39 è un gruppo associato ad attività di spionaggio con focus su telecomunicazioni, viaggi e alta tecnologia. Il loro utilizzo di questa tecnica è pragmatico: hanno impiegato malware per disattivare il flag RequireSigned, permettendo l'esecuzione di DLL non firmate su Windows. Questo approccio, basato sulla manipolazione diretta di una policy applicativa piuttosto che del boot, indica un'operazione mirata alla flessibilità durante il movimento laterale, dove ogni endpoint potrebbe avere configurazioni diverse.

Turla opera a un livello di sofisticazione superiore. Il loro approccio prevede lo sfruttamento di vulnerabilità per ottenere privilegi kernel-mode e poi la modifica diretta delle variabili in memoria kernel per disabilitare DSE. Questo pattern è significativamente più avanzato: non lascia artefatti persistenti su disco, non richiede riavvio e non produce il watermark visivo del Test Mode. È un indicatore di un gruppo che investe in capability kernel e che prioritizza l'evasione rispetto alla semplicità operativa.

Le tre famiglie malware documentate coprono lo spettro delle implementazioni possibili. BlackEnergy usa il percorso più diretto — l'opzione TESTSIGNING nella BCD — per caricare un componente driver. Hikit adotta un approccio Registry-based, manomettendo più chiavi prima di caricare il suo rootkit driver. Pandora rappresenta l'evoluzione più moderna, sfruttando una CVE specifica (CVE-2017-15303) per disabilitare DSE programmaticamente: un esempio concreto del pattern BYOVD.

Il trend emergente è chiaro: i gruppi con capacità avanzate convergono verso la manipolazione in-memory perché minimizza gli artefatti forensi e non richiede il riavvio del sistema — un evento che in ambienti enterprise potrebbe generare alert o ticket di assistenza. Per l'analista TI, la raccomandazione è monitorare i cataloghi di driver vulnerabili noti, perché ogni nuova CVE in un driver firmato amplia il toolbox disponibile per questa tecnica. La convergenza tra T1553.006 e il pattern BYOVD rappresenta la direttrice di sviluppo più probabile per i prossimi trimestri.

Framework MITRE ATT&CK v16 — T1553.006, TA0005. Gruppi: G0087, G0010. Software: S0089, S0009, S0664. Mitigazioni: M1026, M1046, M1024. Detection: DET0523 (AN1446, AN1447). Tool di detection: Sysmon, Volatility 3, Registry Explorer. Integrato con conoscenza professionale per tool e procedure operative.