Iniezione TLS Callback: Thread Local Storage (T1055.005)

Simulare T1055.005 in laboratorio richiede la comprensione della struttura PE, in particolare della IMAGE_DIRECTORY_ENTRY_TLS (indice 9 nella data directory) che punta a una struttura IMAGE_TLS_DIRECTORY contenente il campo AddressOfCallBacks. Questo campo è un array di puntatori a funzione terminato da zero: aggiungendo un puntatore prima del terminatore si ottiene esecuzione automatica al load.

Per costruire un PoC didattico su Windows 10/11 in VM isolata puoi partire da questi strumenti reali:

• PE-bear (open source) o CFF Explorer (gratuito) per ispezionare e modificare la TLS directory di un binario di test
• pefile (open source, Python) per parsing e patching programmatico dei campi PE
• LIEF (open source) come libreria multi-linguaggio per riscrivere sezioni .tls e aggiungere callback
• Process Hacker / System Informer (open source) per verificare thread e memoria del processo target

Una catena tipica in red team simula lo scenario documentato per Ursnif: allocazione di memoria remota nel processo target con VirtualAllocEx, scrittura del payload con WriteProcessMemory, quindi patch della TLS directory del modulo caricato per far puntare AddressOfCallBacks[0] alla shellcode. Il trigger avviene alla creazione del thread successivo, senza chiamare CreateRemoteThread — ed è proprio questo il vantaggio evasivo rispetto a T1055.003.

Per studiare CANONSTAGER, l'approccio è diverso: qui la TLS non serve per iniezione cross-process ma come storage in-process di indirizzi di funzione risolti tramite API hashing custom. Puoi replicare il pattern scrivendo un loader C/C++ che popola TlsAlloc + TlsSetValue con puntatori a LoadLibraryA, GetProcAddress, VirtualProtect risolti via hash (algoritmo tipo djb2 o ROR13), poi invoca le funzioni leggendole da TlsGetValue. Questo pattern rende difficile lo static analysis perché le import non compaiono nella IAT.

Per la fase di weaponization in ambiente controllato, Donut (open source) genera shellcode position-independent da PE/DLL/.NET assembly, ideale come payload da piazzare come TLS callback. Sliver (open source) e Havoc (open source) sono C2 framework che supportano stager custom per test di detection engineering.

Documenta ogni esecuzione con Time Travel Debugging di WinDbg (gratuito) per catturare il flusso dal callback fino al main, materiale prezioso per il team blue.

La detection di T1055.005 si fonda sulla strategia DET0467, che monitora modifiche alla PE header e alla TLS directory in memoria, tipicamente successive a un evento di process hollowing e seguite da attività di thread anomala prima dell'entry point.

Le fonti di log primarie sono Sysmon (open source, Microsoft) e la telemetria memoria dell'EDR. Per Sysmon, la configurazione minima deve includere:

• EventID 8 (CreateRemoteThread) — cattura creazione di thread cross-process
• EventID 10 (ProcessAccess) — rileva OpenProcess con GrantedAccess sospetti come 0x1F0FFF (PROCESS_ALL_ACCESS) o combinazioni 0x1438 tipiche di injection
• EventID 7 (ImageLoad) — correla il caricamento del modulo target con successive scritture
• EventID 1 (ProcessCreate) con IntegrityLevel per spot di privilege escalation

Un template SwiftOnSecurity o la config di Olaf Hartong (entrambe open source su GitHub) forniscono baseline solide. La regola comportamentale chiave correla: (a) ProcessAccess verso processo target con diritti di write memoria, (b) assenza di CreateRemoteThread successivo, (c) attività di rete o spawn di child process dal target entro finestra breve. L'assenza del thread remoto è proprio la firma distintiva di TLS callback injection rispetto ad altre varianti.

Sul fronte EDR, i parametri di tuning suggeriti dalla detection strategy sono:

• TargetProcessFilter: escludere alert su processi il cui TLS callback set è stabile (es. explorer.exe, lsass.exe, winlogon.exe); qualsiasi modifica post-load a questi è ad altissima priorità
• TimeWindowBetweenLoadAndTLSModification: soglia tipica sotto i 5 secondi tra image load e write sulla sezione .tls o .data
• AnomalousThreadStartThreshold: numero di thread eseguiti prima del main entry point (baseline normalmente 0-1)
• PayloadEntropyThreshold: entropia >7.0 su regioni di memoria scritte suggerisce shellcode o codice packed

Regole Sigma utili includono la detection di scritture su regioni RWX in processi non-development, e query KQL su Microsoft Defender for Endpoint tramite tabelle DeviceEvents con ActionType == "WriteToLsassProcess" o eventi di memory injection.

Complementare a M1040 (Behavior Prevention on Endpoint), attivare Attack Surface Reduction rules di Defender come Block credential stealing from LSASS e Block process creations from PSExec and WMI commands riduce la superficie sfruttabile. Falsi positivi tipici arrivano da runtime .NET (JIT compila e scrive in memoria RWX), debugger, installer con self-modifying code e software di protezione DRM: whitelisting per firma Authenticode è essenziale.

L'analisi forense di T1055.005 parte dalla memoria volatile, perché il payload TLS callback risiede quasi interamente in RAM. Volatility 3 (open source) e MemProcFS (open source) sono gli strumenti di riferimento per il triage.

Su un dump acquisito con WinPmem o DumpIt (entrambi gratuiti), i plugin chiave sono:

• windows.malfind — identifica regioni di memoria con permessi RWX e header PE sospetti in processi legittimi
• windows.dlllist e windows.ldrmodules — evidenzia moduli non presenti nel PEB Loader ma mappati in memoria
• windows.pslist / windows.psscan — confronto per individuare discrepanze tra process listing ufficiale e scanning diretto
• windows.vadinfo — dump delle Virtual Address Descriptor per esaminare regioni allocate dinamicamente

Per estrarre e analizzare la TLS directory dal dump del modulo (ottenuto con windows.dumpfiles), usa pefile (open source) leggendo pe.DIRECTORY_ENTRY_TLS.struct.AddressOfCallBacks e confrontando l'array con quello del binario originale su disco. Una divergenza è indicatore forte di manipolazione.

Su filesystem gli artefatti utili sono:

• Prefetch (C:\Windows\Prefetch\*.pf) — analizzato con PECmd di Eric Zimmerman (open source), fornisce timestamp di prima e ultima esecuzione, DLL caricate e volumi acceduti
• Amcache.hve e ShimCache — parsing con AmcacheParser e AppCompatCacheParser (open source) per tracciare esecuzione di binari malevoli
• UserAssist e BAM/DAM nel registry — evidenze aggiuntive di esecuzione utente/servizio
• MFT e USN Journal — estratti con MFTECmd (open source) per timeline di creazione/modifica dei file coinvolti

La timeline si costruisce con plaso/log2timeline (open source) unendo Sysmon, Security log (EventID 4688 per process creation con command line), MFT e prefetch. L'attenzione va focalizzata sulla finestra temporale in cui il processo target è stato lanciato: cerca ProcessAccess Sysmon (EventID 10) verso quel PID nei minuti immediatamente precedenti l'attività anomala di rete.

Per il caso Ursnif, artefatti storici documentati includono file droppati in %APPDATA% con nomi randomici, chiavi Run per persistenza e traffico HTTPS verso C2 con pattern URI riconoscibili. Per CANONSTAGER, l'analisi statica del binario con Ghidra (open source) o IDA Free (gratuito) rivela il pattern di API hashing e l'uso di TlsAlloc/TlsSetValue/TlsGetValue per storage di puntatori risolti dinamicamente — firma comportamentale che permette hunting su larga scala tramite regole YARA che matchano la sequenza di hash constants nel codice.

Il quadro di threat intelligence per T1055.005 è caratterizzato dall'assenza di attribuzioni APT dirette nei dati MITRE, ma dalla presenza di due famiglie malware significative che illustrano usi profondamente diversi della tecnica.

Ursnif (S0386), noto anche come Gozi ISFB o Dreambot, è uno dei banking trojan più longevi e prolifici del panorama cybercrime. La sua codebase deriva dal leak del sorgente originale di Gozi (2010) e ha generato molteplici fork gestiti da attori financially-motivated, principalmente attivi contro istituti bancari in Italia, Giappone, Nord America ed Europa dell'Est. L'uso di TLS callback injection in Ursnif si inserisce in una lunga tradizione di innovazione evasiva della famiglia, che include anche steganografia via PowerShell, DGA per C2 e hooking di API browser per web injection. La tecnica gli consente di iniettare codice in processi come explorer.exe o browser senza generare thread remoti visibili — evadendo detection basate su CreateRemoteThread.

CANONSTAGER (S1237) rappresenta invece un uso diverso e più raffinato: qui il TLS non serve per injection cross-process ma come struttura dati in-process per memorizzare indirizzi di funzione risolti tramite un algoritmo custom di API hashing. Questo pattern è tipico di loader/stager di gruppi capaci, spesso attribuiti a operazioni di targeted espionage. L'uso della TLS array come storage aiuta a: (a) evitare che le API sensibili compaiano nella IAT, (b) rendere l'analisi statica più complessa richiedendo emulation o debug per risolvere gli hash, (c) confondere gli scanner YARA basati su string matching.

Il pattern strategico che emerge dai due casi è che T1055.005 non è appannaggio di uno specifico attore ma è una capability trasversale, adottata sia da criminalità organizzata (cluster Ursnif) sia da threat actor più sofisticati orientati allo staging silenzioso. La barriera d'ingresso è medio-alta perché richiede conoscenza della struttura PE e capacità di manipolare memoria remota, ma esistono PoC pubblici da anni che ne facilitano l'adozione.

Dal punto di vista dei tool overlap, entrambe le famiglie si combinano frequentemente con Process Hollowing (T1055.012) come primitiva di supporto, con Reflective DLL Loading e con tecniche di API Hashing (T1027.007). Il trend osservabile è la migrazione di tecniche come TLS injection da malware bancario a loader modulari usati in intrusion multi-stage, dove lo staging silenzioso è prerequisito per il successivo deployment di beacon C2 o ransomware. Per un CTI officer, la priorità è mantenere feed YARA aggiornati su varianti Ursnif e monitorare campagne di spearphishing che veicolano loader con caratteristiche simili a CANONSTAGER, spesso distribuiti tramite ISO/IMG con LNK e sideloading di DLL firmate.

MITRE ATT&CK: tecnica T1055.005, tattiche TA0004 e TA0005, software S0386 Ursnif e S1237 CANONSTAGER, mitigazione M1040 Behavior Prevention on Endpoint, detection strategy DET0467 con analytic AN1289. Framework difensivo MITRE D3FEND per artefatti Process/Module. Le sezioni operative integrano conoscenza professionale di cybersecurity su tool open source (Volatility 3, Sysmon, pefile, LIEF, Ghidra) e sintassi PE Windows verificata su documentazione Microsoft ufficiale.