Iniezione DLL nei Processi: Dynamic-link Library Injection (T1055.001)

La simulazione dell'iniezione DLL in laboratorio è un esercizio fondamentale per validare i controlli EDR e le regole Sysmon. L'approccio più immediato sfrutta framework già strutturati, ma è utile comprendere anche la meccanica manuale.

Cobalt Strike (a pagamento) offre il comando nativo di iniezione DLL, che replica fedelmente la catena VirtualAllocEx → WriteProcessMemory → CreateRemoteThread. In una sessione Beacon attiva, il flusso operativo prevede di identificare un processo target con ps, quindi eseguire:

shinject <PID> x64 <percorso_shellcode>

Per la reflective DLL injection, Cobalt Strike utilizza internamente il meccanismo reflective loader quando si lancia dllinject <PID> su un Beacon attivo. Questo replica esattamente ciò che gruppi come Lazarus Group e Leviathan impiegano nelle loro operazioni reali.

Con Metasploit Framework (open source), l'iniezione riflettiva è altrettanto accessibile. Dopo aver ottenuto una sessione Meterpreter, il comando migrate sposta l'agente in un altro processo tramite reflective injection:

meterpreter > migrate <PID>

Questa è la stessa tecnica documentata per Turla, che usa Metasploit per l'escalation dei privilegi tramite reflective DLL injection.

PowerSploit (open source) fornisce il modulo Invoke-DllInjection all'interno della collezione CodeExecution. Da una sessione PowerShell con privilegi adeguati:

Invoke-DllInjection -ProcessID <PID> -Dll <percorso_dll>

Per simulare la variante Module Stomping, Pupy (open source) permette la migrazione tra processi con reflective injection attraverso il comando migrate del suo agente, replicando un comportamento osservato in diversi sample analizzati.

Un approccio più granulare prevede la compilazione di un injector custom in C che richiami la sequenza classica delle tre API. Il vantaggio didattico è totale visibilità sulla catena di chiamate, permettendo di correlare ogni step con gli eventi Sysmon generati. Per il Module Stomping, l'injector deve caricare una DLL legittima nel processo remoto con LoadLibraryEx usando il flag DONT_RESOLVE_DLL_REFERENCES, sovrascrivere il suo AddressOfEntryPoint con WriteProcessMemory, e avviare un thread sull'entry point modificato.

Durante il test, monitorate sempre con Sysmon (open source, distribuito da Microsoft Sysinternals) gli eventi generati: EventCode 8 (CreateRemoteThread), EventCode 10 (ProcessAccess) e EventCode 7 (ImageLoad). Questo vi darà la baseline per validare le detection nella sezione successiva.

La detection dell'iniezione DLL si basa sulla correlazione temporale di eventi che, presi singolarmente, sono legittimi. Il sistema operativo Windows usa CreateRemoteThread e LoadLibrary in contesti normali — il punto è identificare le sequenze anomale.

La fonte primaria è Sysmon, la cui configurazione deve catturare tre classi di eventi. L'EventCode 8 (CreateRemoteThread) registra ogni creazione di thread in un processo remoto: filtrate per i processi target ad alto valore come explorer.exe, svchost.exe, winlogon.exe e dllhost.exe — tutti bersagli documentati nel dataset. L'EventCode 10 (ProcessAccess) cattura le richieste di accesso con diritti di scrittura in memoria remota: le access mask 0x1F0FFF (PROCESS_ALL_ACCESS) e 0x0020 (PROCESS_VM_WRITE) combinate con 0x0008 (PROCESS_VM_OPERATION) sono indicatori forti. L'EventCode 7 (ImageLoad) registra il caricamento di DLL: concentrate l'attenzione su DLL non firmate o caricate da percorsi non standard (directory temporanee, AppData, cartelle utente).

La regola di correlazione comportamentale indicata nella detection DET0389 prevede di correlare in una finestra temporale ristretta (5-10 secondi) tre eventi: allocazione di memoria remota, scrittura nel processo target e creazione di un thread remoto che carica una DLL sospetta. I parametri di tuning critici sono quattro:

• InjectedDLLSignatureStatus: filtrare per DLL non firmate, con firma non attendibile o caricate da percorsi non standard
• TimeWindow: la soglia temporale tra operazioni di memoria e creazione del thread — troppo ampia genera rumore, troppo stretta perde varianti lente
• TargetProcessList: la lista dei processi sensibili — i dati mostrano che svchost.exe, explorer.exe, winlogon.exe, rundll32.exe e dllhost.exe sono i target più frequenti
• ParentProcessAnomalyThreshold: la deviazione dalla gerarchia parent-child attesa — un processo Word (winword.exe) che inietta in svchost.exe, come fa TA505, è un'anomalia chiara

Per la reflective injection, il caricamento non passa per LoadLibrary e quindi l'EventCode 7 potrebbe non attivarsi. In questo caso, la detection si sposta su ETW (Event Tracing for Windows): il provider Microsoft-Windows-Threat-Intelligence cattura le operazioni di allocazione di memoria con permessi RWX (Read-Write-Execute) in processi remoti. Soluzioni EDR come Microsoft Defender for Endpoint (a pagamento) e Elastic Security (freemium) integrano nativamente questi telemetria.

La mitigazione primaria è Behavior Prevention on Endpoint (M1040): configurare l'EDR per bloccare sequenze di API calls sospette come OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread. I falsi positivi più comuni provengono da software di virtualizzazione, tool di accessibilità e alcuni antivirus che iniettano le proprie DLL di hooking — manteneteli in una whitelist aggiornata.

L'analisi forense dell'iniezione DLL richiede una combinazione di memory forensics e correlazione con artefatti su disco. La memoria volatile è la fonte primaria: senza di essa, molte varianti riflettive non lasciano tracce persistenti.

Volatility 3 (open source) è lo strumento cardine per l'analisi del dump di memoria. Il plugin windows.malfind identifica regioni di memoria con permessi sospetti (PAGE_EXECUTE_READWRITE) all'interno dei processi, rivelando codice iniettato che non corrisponde a nessun file mappato su disco:

python3 vol.py -f <memory_dump> windows.malfind

Le regioni marcate con protezione RWX che contengono header PE (i caratteristici byte MZ all'inizio) sono un indicatore forte di DLL iniettata riflessivamente. Per approfondire, il plugin windows.dlllist confronta le DLL caricate nel processo con quelle effettivamente presenti nel PEB (Process Environment Block):

python3 vol.py -f <memory_dump> windows.dlllist --pid <PID>

Una discrepanza — moduli presenti in memoria ma assenti dalla lista del PEB — è la firma tipica della reflective injection. Il plugin windows.handles aiuta a identificare handle aperti tra processi, ricostruendo quale processo ha ottenuto accesso al target per l'iniezione.

Per il Module Stomping, cercate DLL legittime il cui contenuto in memoria diverge dalla copia su disco. Estraete il modulo dalla memoria con windows.dumpfiles e confrontatelo con l'originale: una differenza nell'area dell'entry point conferma la sovrascrittura.

Sul fronte degli artefatti su disco, gli event log di Sysmon sono fondamentali per ricostruire la timeline. In un'acquisizione forense, estraete il file Microsoft-Windows-Sysmon%4Operational.evtx e cercate la sequenza di EventCode 10 → EventCode 8 → EventCode 7 correlata al PID target. La campagna C0015 offre un esempio concreto: gli attaccanti hanno iniettato una DLL denominata D8B3.dll nel processo Winlogon, utilizzando poi Cobalt Strike e Conti per le fasi successive. In un caso simile, la timeline mostrerebbe un evento ProcessAccess verso winlogon.exe, seguito da CreateRemoteThread e dal caricamento di una DLL con nome pseudo-casuale.

I Prefetch files (in C:\Windows\Prefetch) possono rivelare l'esecuzione dell'injector: cercate file .pf associati a eseguibili non riconosciuti che referenziano le DLL di sistema utilizzate per l'iniezione (kernel32.dll, ntdll.dll). Lo Shimcache (AppCompatCache nel registro SYSTEM) registra i binari eseguiti anche se successivamente cancellati, fornendo un ulteriore punto di ancoraggio temporale.

Per le varianti che iniettano in rundll32.exe — comportamento documentato per Heyoka Backdoor, SDBbot, MegaCortex e Mongall — verificate nella timeline se rundll32.exe è stato avviato senza argomenti o con argomenti inusuali: l'avvio di un rundll32.exe "vuoto" è un indicatore di processo creato come contenitore per l'iniezione.

L'iniezione DLL è trasversale: la utilizzano gruppi di spionaggio statale, operatori ransomware e attori finanziari. Questa universalità la rende un indicatore debole per l'attribuzione se presa isolatamente, ma i pattern specifici — variante utilizzata, processo target, tool impiegato — raccontano storie diverse.

Turla (G0010) utilizza Metasploit per la reflective DLL injection specificamente come vettore di privilege escalation. Questo è coerente con il profilo di un gruppo che dispone di tool custom sofisticati (come il loro ComRAT, che inietta il proprio orchestratore in explorer.exe e il modulo di comunicazione nel browser predefinito della vittima) ma ricorre a framework pubblici per le fasi meno critiche. La scelta di iniettare nel browser per mascherare il traffico C2 è una firma comportamentale distintiva.

Lazarus Group (G0032) e Leviathan (G0065) condividono l'uso della reflective DLL injection, ma con obiettivi differenti. Lazarus la impiega come componente dei propri malware custom, mentre Leviathan la usa per scrivere una DLL in memoria e caricare una shell di backdoor. Entrambi i gruppi operano nell'area Asia-Pacifico, ma con mandati distinti — finanziario e spionaggio rispettivamente — che si riflettono nelle fasi successive della kill chain.

Wizard Spider (G0092) e TA505 (G0081) rappresentano il versante finanziario. Wizard Spider inietta DLL con permessi RWX completi, un approccio aggressivo coerente con la velocità operativa richiesta dalle campagne ransomware. TA505 inietta specificamente in winword.exe, sfruttando il fatto che il processo Word ha accesso alla rete e la sua attività di rete è meno sospetta. La campagna C0015 — un'intrusione ransomware di 5 giorni che ha utilizzato Bazar, Cobalt Strike e Conti — esemplifica come l'iniezione in Winlogon venga combinata con tool multipli seguendo il playbook Conti pubblicamente circolato.

Tropic Trooper (G0081) inietta backdoor DLL in dllhost.exe e svchost.exe, processi di sistema che generano numerose istanze legittime e quindi offrono copertura ottimale. BackdoorDiplomacy (G0135) adotta un approccio diverso: scarica software legittimo sul sistema compromesso e lo usa come veicolo per eseguire DLL malevole, una tecnica che si sovrappone al DLL side-loading.

Putter Panda (G0024) sceglie i propri target di iniezione tra i processi che normalmente accedono alla rete — Outlook Express, Outlook, Internet Explorer e Firefox — replicando lo stesso pattern di "mimetismo nel traffico di rete" osservato in ComRAT di Turla. Malteiro (G1026) inietta la DLL di Mispadu nei processi, confermando l'adozione della tecnica anche nel panorama del cybercrime latinoamericano.

Il trend emergente è lo spostamento verso varianti che evitano la catena API classica: reflective injection, Module Stomping e memory-only execution riducono la superficie di detection tradizionale. La risposta difensiva si sposta necessariamente verso la telemetria a livello kernel (ETW Threat Intelligence) e la memory forensics.

Framework MITRE ATT&CK v16 — T1055.001 (Dynamic-link Library Injection), tattiche TA0005 e TA0004. Campagna C0015. Detection DET0389 con analisi AN1095. Mitigazione M1040 (Behavior Prevention on Endpoint). Tool di detection e analisi: Sysmon, Volatility 3, Elastic Security, Microsoft Defender for Endpoint. Integrato con conoscenza professionale per tool e procedure operative.