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

La catena d'attacco classica su Windows si basa su tre chiamate API in sequenza: VirtualAllocEx per allocare memoria nel processo remoto, WriteProcessMemory per scrivervi il percorso della DLL, e CreateRemoteThread per invocare LoadLibrary nel contesto del bersaglio. Comprendere questa sequenza è fondamentale prima di passare ai tool.

Cobalt Strike offre il modulo di reflective DLL injection integrato. Dopo aver ottenuto una sessione Beacon, il comando inject consente di selezionare il PID del processo target e caricare una DLL direttamente in memoria, senza che questa tocchi il disco. La stessa tecnica è disponibile in PowerSploit, che include una collezione di moduli CodeExecution per iniettare DLL e shellcode in un processo. Il cmdlet di riferimento è:

Invoke-ReflectivePEInjection -PEPath C:\payload.dll -ProcId [PID]

Pupy, il framework post-exploitation in Python, permette la migrazione in un altro processo tramite reflective DLL injection con un singolo comando dalla console dell'agente. Koadic, invece, sfrutta un approccio basato su JScript/VBScript per eseguire process injection tramite DLL riflessiva.

Per simulare la variante classica — quella che scrive la DLL su disco — si può replicare il comportamento di FunnyDream, il cui componente FilepakMonitor inietta nel processo Bka.exe usando esattamente la triade VirtualAllocEx, WriteProcessMemory e CreateRemoteThread. Un PoC in C minimale segue questa logica:

hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, targetPID); pRemote = VirtualAllocEx(hProc, NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); WriteProcessMemory(hProc, pRemote, dllPath, dwSize, NULL); CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)LoadLibraryA, pRemote, 0, NULL);

Per testare il Module Stomping, il flusso richiede un passo aggiuntivo: si carica prima una DLL legittima nel processo remoto, si ottiene l'indirizzo del suo entry point, lo si sovrascrive con il payload malevolo, e infine si avvia il thread. Questa variante è particolarmente insidiosa perché la DLL su disco risulta firmata e legittima.

I processi bersaglio più comuni negli scenari reali includono explorer.exe, svchost.exe, rundll32.exe, dllhost.exe, winlogon.exe e browser come iexplore.exe e firefox.exe. In laboratorio, è consigliabile testare l'iniezione contro ciascuno di questi per verificare le differenze nei livelli di integrità e nelle policy di protezione.

La detection di questa tecnica ruota attorno alla correlazione temporale di eventi specifici, non al singolo log isolato. L'analisi comportamentale documentata (DET0389) descrive con precisione il pattern da intercettare: allocazione di memoria in un processo remoto, scrittura in quella memoria e creazione di un thread remoto che carica una DLL sospetta o non firmata.

La sorgente primaria è Sysmon, configurato per catturare eventi di creazione processo (EventCode 1), caricamento immagini (EventCode 7) e accesso a processi remoti (EventCode 10). L'EventCode 10 è il cuore della detection: quando un processo invoca OpenProcess con diritti di scrittura su un altro processo, Sysmon registra il chiamante, il bersaglio e i permessi richiesti. Correlando questo evento con un successivo EventCode 7 — caricamento di una DLL non firmata nel processo target — si ottiene un indicatore ad alta fedeltà.

I parametri di tuning sono cruciali per evitare il diluvio di falsi positivi:

• InjectedDLLSignatureStatus: filtra sulle DLL non firmate, con firma non attendibile o caricate da percorsi non standard (es. %TEMP%, %APPDATA%)
• TimeWindow: imposta una finestra di correlazione stretta (pochi secondi) tra l'allocazione di memoria e la creazione del thread remoto
• TargetProcessList: concentra gli alert sui processi ad alto valore come explorer.exe, winlogon.exe, svchost.exe, lsass.exe
• ParentProcessAnomalyThreshold: segnala deviazioni dalla normale gerarchia padre-figlio (es. winword.exe che inietta in svchost.exe, come documentato per TA505)

La mitigazione ufficiale Behavior Prevention on Endpoint (M1040) prevede che le soluzioni EDR monitorino le sequenze di chiamate API OpenProcess → WriteProcessMemory → CreateRemoteThread e le blocchino in tempo reale. Configurare l'EDR per terminare il processo offendente, non solo generare un alert, riduce drasticamente il tempo di permanenza dell'attaccante.

I falsi positivi più comuni provengono da software di virtualizzazione, tool di accessibility e framework di automazione che utilizzano legittimamente l'injection per funzionalità di hooking. La creazione di una whitelist basata su hash del chiamante e certificato digitale permette di escludere queste sorgenti senza perdere copertura.

L'analisi forense di un'iniezione DLL parte dalla memoria volatile. Un dump del processo sospetto con Volatility rivela le DLL caricate nello spazio di indirizzamento: confrontando la lista dei moduli con quelli attesi per quel processo, le anomalie emergono rapidamente. Una DLL non firmata caricata in svchost.exe da %TEMP% è un segnale inequivocabile.

Durante la campagna C0015 — un'intrusione ransomware durata 5 giorni in cui gli attaccanti utilizzarono Bazar, Cobalt Strike e Conti — la DLL malevola D8B3.dll fu iniettata nel processo winlogon.exe. Questo artefatto rappresenta un caso esemplare: la scelta di winlogon garantisce persistenza implicita e privilegi SYSTEM, rendendo l'iniezione particolarmente efficace.

Su Windows, gli artefatti chiave da raccogliere includono i log Sysmon (EventCode 10 per l'accesso al processo, EventCode 7 per il caricamento della DLL), i log del Security Event Log (EventCode 4688 per la creazione processi con command line auditing abilitato), e le chiavi di registro che tracciano i moduli caricati. Il file system va esaminato per DLL anomale nelle directory temporanee, nella cartella utente e nei percorsi di download.

Per la ricostruzione della timeline, il flusso tipico segue queste fasi:

1. Il dropper scrive la DLL malevola su disco (o la mantiene in memoria nelle varianti reflective)
2. Il processo attaccante apre un handle verso il processo target con diritti elevati
3. La memoria viene allocata e il payload scritto nello spazio remoto
4. Un thread remoto viene creato per eseguire il caricamento
5. La DLL malevola inizia la comunicazione C2 dal contesto del processo legittimo

Un dettaglio forensico rilevante emerge dal comportamento di ComRAT (usato da Turla): il malware inietta il modulo di comunicazione nel browser predefinito della vittima, così che tutto il traffico C2 appaia come normale navigazione web. Questo complica l'analisi di rete se non si correla con gli artefatti di memoria. Analogamente, Duqu seleziona il processo target in funzione dell'antivirus installato sul sistema, dimostrando un livello di adattamento che richiede al forensic analyst di documentare l'intero stack di sicurezza presente al momento della compromissione.

Sui sistemi in cui la DLL non ha toccato il disco — come nel caso di RARSTONE, che scarica la DLL dal C2 e la carica direttamente nella memoria di un processo Internet Explorer nascosto — la memory forensics è l'unico approccio percorribile.

L'iniezione DLL è una tecnica trasversale, adottata tanto da gruppi di cyber-espionage quanto da operatori ransomware. I profili seguenti rivelano pattern distinti nell'impiego di questa capacità.

Turla (G0010) utilizza Metasploit per eseguire reflective DLL injection specificamente per l'escalation di privilegi. Il gruppo russo di cyber-espionage è noto per il suo arsenale sofisticato — Uroburos e ComRAT sono entrambi capaci di iniezione DLL — e la scelta di iniettare il modulo di comunicazione nel browser predefinito della vittima rivela una priorità operativa sulla stealth delle comunicazioni C2 rispetto alla mera esecuzione del payload.

Lazarus Group (G0032) impiega reflective DLL injection nei propri malware sample, una tecnica coerente con la tendenza del gruppo nordcoreano a operare prevalentemente in memoria per evitare la detection basata su file. Il loro approccio si allinea con campagne di spionaggio e furto finanziario che richiedono persistenza prolungata e bassa visibilità.

Wizard Spider (G0102), il gruppo dietro le operazioni ransomware con Conti e correlato alla campagna C0015, inietta DLL malevole in memoria con permessi di lettura, scrittura ed esecuzione. La catena d'attacco documentata — Bazar come loader iniziale, Cobalt Strike per il movimento laterale, Conti per il ransomware — mostra come l'iniezione DLL sia un tassello in una kill chain industrializzata.

Leviathan (G0065), gruppo cinese focalizzato su settori marittimo e difesa, utilizza reflective DLL loading per scrivere una DLL in memoria e caricare una shell di backdoor. BackdoorDiplomacy (G0135), anch'esso attribuito ad attori cinesi, adotta un approccio diverso: deposita software legittimo sull'host compromesso e lo usa come veicolo per eseguire DLL malevole, una tecnica che sfrutta la fiducia nei binari noti per eludere l'application whitelisting.

Il pattern geografico è netto: i gruppi russi (Turla) e cinesi (Leviathan, BackdoorDiplomacy, Tropic Trooper) privilegiano l'iniezione DLL per operazioni di lungo periodo, mirando a processi di sistema come dllhost.exe e svchost.exe. I gruppi con finalità finanziarie — TA505 che inietta in winword.exe, Malteiro che usa Mispadu — puntano invece su processi applicativi per massimizzare l'accesso ai dati dell'utente. L'overlap di tool è significativo: Cobalt Strike e Metasploit compaiono sia negli arsenali statali sia in quelli criminali, rendendo l'attribuzione basata sul solo tooling insufficiente.

Framework MITRE ATT&CK — T1055.001 (Dynamic-link Library Injection). Campagna C0015 (ransomware Conti, 2021). Detection DET0389 con analisi AN1095 (correlazione API Windows via Sysmon). Mitigazione M1040 (Behavior Prevention on Endpoint).