Application Shimming: Event Triggered Execution — Application Shimming (T1546.011)

L'obiettivo di un red teamer è dimostrare come un attaccante con privilegi amministrativi locali possa installare uno shim database malevolo e ottenere persistenza o escalation. Il flusso di lavoro si articola in tre fasi: creazione del database, installazione e validazione.

Creazione del database .sdb. Lo strumento nativo per compilare shim database è il Compatibility Administrator, parte del Windows Assessment and Deployment Kit (a pagamento come parte di Windows ADK, ma scaricabile gratuitamente dal sito Microsoft). Dopo aver aperto l'applicazione, si crea un "New Application Fix" specificando il binario target — ad esempio notepad.exe — e applicando uno shim come InjectDLL per caricare una DLL arbitraria o RedirectEXE per redirigere l'esecuzione verso un payload. Il database viene salvato come file .sdb.

Per scenari automatizzati in laboratorio, il tool sdb-explorer (open source) consente di analizzare e manipolare file .sdb da riga di comando, utile per ispezionare database esistenti e comprenderne la struttura interna.

L'installazione avviene tramite l'utility nativa di Windows:

sdbinst.exe C:\temp\payload.sdb

Questo comando registra il database nel sistema. Per verificare l'avvenuta installazione, interroga il registro:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB"

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom"

Entrambe le chiavi dovranno mostrare l'entry corrispondente al file .sdb appena installato. Come ulteriore verifica, controlla la presenza fisica del file nella directory:

dir %WINDIR%\AppPatch\Custom*.sdb

Per una simulazione con framework offensivi, Metasploit (open source) include il modulo post/windows/manage/install_shim che automatizza la creazione e l'installazione dello shim database su una sessione Meterpreter con privilegi elevati. In alternativa, il progetto ShimRatReporter (open source, disponibile su GitHub) fornisce un approccio didattico all'analisi degli shim presenti su un sistema.

Al termine del test, la rimozione è obbligatoria:

sdbinst.exe -u C:\temp\payload.sdb

Una nota operativa: testa sempre in un ambiente isolato. Shim come DisableNX rimuovono la Data Execution Prevention dal processo target, creando condizioni favorevoli anche per exploit accidentali. Documenta ogni .sdb installato con hash SHA-256 nel report finale.

La detection dell'Application Shimming ruota attorno a tre pilastri: monitoraggio del processo sdbinst.exe, sorveglianza delle chiavi di registro AppCompatFlags e ispezione delle directory dove risiedono i file .sdb. La strategia di analisi correlata (DET0017, AN0051) combina questi tre segnali in una finestra temporale configurabile per ridurre il rumore.

Log source critici. Configura Sysmon (open source, di Sysinternals) come fonte primaria. L'EventID 1 (Process Creation) cattura ogni invocazione di sdbinst.exe con la relativa command line, che rivela il percorso del file .sdb installato. L'EventID 12 e 13 (Registry Create/Set Value) tracciano le modifiche alle chiavi AppCompatFlags\InstalledSDB e AppCompatFlags\Custom. Infine, l'EventID 11 (File Creation) registra la scrittura di nuovi file .sdb nelle directory AppPatch\Custom.

Dal lato Windows Security Log, l'EventID 4688 (Process Creation) con audit delle command line abilitato fornisce un backup se Sysmon non è deployato. Attiva questa funzione tramite la Group Policy "Include command line in process creation events".

La regola di correlazione principale segue questa logica: se sdbinst.exe viene eseguito in contesto amministrativo o SYSTEM, e entro una finestra di N minuti si osserva una modifica alle chiavi AppCompatFlags, genera un alert di severità alta. Il tuning è essenziale per evitare falsi positivi: gli shim installati da processi di deployment software legittimi (SCCM, PDQ Deploy) producono lo stesso pattern.

Per il tuning, mantieni una allowlist dei percorsi .sdb noti nel tuo ambiente. I parametri suggeriti dalla detection AN0051 sono cinque:

• CustomShimPathAllowlist: percorsi .sdb legittimi già censiti
• TimeWindow: finestra di correlazione tra esecuzione e modifica registro
• DLLInjectionTarget: binari attesi come target di shim legittimi
• UserContext: limita gli alert a installazioni in contesto admin/SYSTEM
• ShimCommandLinePattern: pattern di command line benigni da escludere

Per il rilevamento dell'iniezione DLL post-shim, monitora l'EventID 7 di Sysmon (Image Loaded) cercando DLL caricate da processi shimmed che non appartengono ai percorsi attesi. Strumenti come Elastic Security (freemium) e Splunk (a pagamento) offrono regole predefinite per questo scenario. Per ambienti con budget ridotto, Sigma (open source) fornisce regole convertibili per qualsiasi SIEM.

Infine, come controllo preventivo, la mitigazione M1052 suggerisce di configurare UAC su "Always Notify" e di applicare la patch KB3045645, che rimuove il flag auto-elevate da sdbinst.exe, impedendo il bypass UAC tramite shimming.

L'analisi forense di un attacco basato su Application Shimming inizia dalla ricerca degli artefatti su disco e nel registro, per poi ricostruire la sequenza temporale che collega l'installazione dello shim alla persistenza o all'escalation osservata.

Artefatti sul file system. La prima tappa è l'ispezione delle directory shim. I database personalizzati risiedono in %WINDIR%\AppPatch\Custom e %WINDIR%\AppPatch\AppPatch64\Custom. Ogni file .sdb trovato in queste directory che non appartenga all'installazione base di Windows è potenzialmente sospetto. Calcola l'hash SHA-256 di ogni file e confrontalo con i repository di threat intelligence. Per analizzare il contenuto interno del database, lo strumento sdb2xml (incluso nel Windows SDK, gratuito) converte il file binario .sdb in formato XML leggibile, rivelando quali shim sono applicati, quali binari sono target e quali DLL vengono iniettate.

Artefatti nel registro. Le chiavi fondamentali sono due:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB — elenca i database installati tramite sdbinst.exe, ciascuno con un GUID univoco, percorso e timestamp
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom — mappa i binari target ai GUID dei database che li intercettano

Estraendo i timestamp di ultima modifica di queste chiavi e correlandoli con i metadati NTFS ($MFT, $STANDARD_INFORMATION) dei file .sdb, è possibile stabilire il momento esatto dell'installazione. Usa RegRipper (open source) con il plugin appcompatflags per automatizzare l'estrazione da hive offline.

Shim Cache e AmCache. Lo Shimcache (noto anche come AppCompatCache, memorizzato nella chiave HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache) registra i metadati degli eseguibili valutati dal framework di compatibilità. Il tool AppCompatCacheParser di Eric Zimmerman (open source) estrae questa struttura in formato CSV, fornendo path, dimensione e timestamp di ultima modifica degli eseguibili. Incrociando questi dati con le entry dell'AmCache (%WINDIR%\appcompat\Programs\Amcache.hve), analizzabile tramite AmcacheParser (open source), si ottiene conferma dell'esecuzione del binario target e del payload.

Ricostruzione della timeline. Ordina cronologicamente: creazione del file .sdb → esecuzione di sdbinst.exe (da Prefetch o Shimcache) → modifica delle chiavi AppCompatFlags → prima esecuzione del processo target con DLL iniettata. I Prefetch file di sdbinst.exe (C:\Windows\Prefetch\SDBINST.EXE-*.pf) confermano l'esecuzione e includono i riferimenti ai file .sdb caricati. Analizzali con PECmd (open source) di Eric Zimmerman.

In casi legati a SDBbot, cerca uno shim che patcha services.exe — un target insolito che rappresenta un forte indicatore di compromissione.

L'Application Shimming è una tecnica di nicchia, ma il gruppo che la impiega e i malware associati offrono spunti analitici significativi per il profiling delle minacce.

FIN7 (G0046) è il gruppo APT più rilevante in questo contesto. Conosciuto per le operazioni finanziarie contro il settore retail e hospitality, FIN7 ha utilizzato shim database per mantenere la persistenza su sistemi compromessi. L'adozione di questa tecnica si inserisce in un modus operandi più ampio: FIN7 privilegia meccanismi di persistenza che sfruttano funzionalità native di Windows, riducendo la superficie di detection rispetto a tool personalizzati. L'uso del shimming suggerisce che il gruppo opera su ambienti dove le applicazioni legacy sono ancora presenti — un tratto tipico dei sistemi point-of-sale e dei back-office del settore retail.

Pillowmint (S0517) è un malware direttamente associato alle operazioni FIN7 nel settore dei pagamenti. Utilizza un shim database malevolo come meccanismo primario di persistenza, il che lo rende un esempio emblematico di come il shimming venga integrato in catene d'attacco reali orientate al furto di dati delle carte di credito. L'analista TI dovrebbe cercare hash e indicatori legati a Pillowmint ogni volta che identifica shim database sospetti in ambienti POS.

SDBbot (S0461) presenta un comportamento condizionale particolarmente interessante: il malware verifica se opera con privilegi amministrativi e se il sistema è Windows XP o 7, e solo in quel caso installa uno shim database che patcha services.exe. Questa logica rivela due elementi: il malware è progettato per ambienti enterprise con parco macchine eterogeneo, e il targeting di services.exe — il Service Control Manager di Windows — indica un obiettivo di persistenza a livello di sistema.

ShimRat (S0444) è un RAT che installa i propri shim database nella cartella AppPatch. Il nome stesso del malware tradisce il legame intrinseco con la tecnica. ShimRat rappresenta l'evoluzione del concetto: non uno shim come vettore ausiliario, ma come componente architetturale centrale del malware.

Dal punto di vista dei pattern, emerge un filo conduttore chiaro: il shimming viene impiegato prevalentemente contro ambienti con sistemi legacy, dove la probabilità che shim database legittimi siano già presenti è alta — offrendo copertura al malware. Il declino progressivo di Windows 7 e XP potrebbe ridurre l'attrattività della tecnica, ma finché esistono ambienti industriali, sanitari o retail con sistemi operativi non aggiornati, l'Application Shimming resterà un vettore valido. L'analista TI dovrebbe monitorare con attenzione ogni nuovo sample che interagisca con le API di Application Compatibility, correlandolo con gli indicatori noti di FIN7 e delle tre famiglie malware mappate.

Framework MITRE ATT&CK v16 — T1546.011 (Event Triggered Execution: Application Shimming), G0046, S0517, S0461, S0444, M1052, M1051, DET0017/AN0051. Tool di detection: Sysmon, RegRipper, AppCompatCacheParser, AmcacheParser, PECmd, sdb2xml. Integrato con conoscenza professionale per tool e procedure operative.