Iniezione di Eseguibili in Memoria: Portable Executable Injection (T1055.002)

L'obiettivo in laboratorio è riprodurre la sequenza completa di PE injection per validare la detection dell'EDR e calibrare le soglie di alerting. Serve un ambiente isolato con un host Windows 10/11, Sysmon configurato e un processo target sacrificabile.

Approccio classico con API native. Il flusso minimo in C/C++ prevede quattro chiamate: OpenProcess per ottenere un handle con diritti PROCESS_ALL_ACCESS, VirtualAllocEx con protezione PAGE_EXECUTE_READWRITE, WriteProcessMemory per scrivere il PE nel buffer allocato, e infine CreateRemoteThread che punta all'entry point ricalcolato. Per gestire il rebasing, il loader deve iterare la tabella .reloc del PE e applicare il delta tra l'indirizzo allocato e l'ImageBase originale; senza questo passaggio, qualsiasi riferimento assoluto nel codice iniettato punterà a memoria non valida.

Per chi preferisce un framework strutturato, Brute Ratel C4 (a pagamento) offre nativamente la capacità di iniettare payload — nel dataset documentato, l'iniezione di Latrodectus dentro Explorer.exe — attraverso il suo operatore di badger. In alternativa, Havoc (open source) implementa l'auto-iniezione in WerFault.exe, un pattern che sfrutta la fiducia implicita dei SOC verso i processi di crash reporting.

Un esercizio più granulare si realizza con pe-sieve (open source), tool di hasherezade che può essere eseguito dopo l'iniezione per verificare se il payload è rilevabile tramite scansione della memoria del processo:

pe-sieve.exe /pid <PID_target> /shellc /iat 2

Questo comando scansiona il processo specificato alla ricerca di moduli PE non mappati da disco, shellcode e anomalie nella Import Address Table, producendo un report JSON che dettaglia le regioni sospette. È utile per confrontare ciò che l'EDR rileva rispetto a ciò che è effettivamente presente in memoria.

Per replicare il pattern di Gootloader — che utilizza un proprio PE loader interno per eseguire payload interamente in memoria — si può usare il modulo execute-assembly o il reflective loader di Cobalt Strike (a pagamento), oppure il progetto sRDI (open source) che converte una DLL in shellcode position-independent, simulando il caricamento senza passare per LoadLibrary.

Una checklist rapida per il lab:

• Abilitare Sysmon con configurazione che catturi EventID 8 (CreateRemoteThread) e EventID 10 (ProcessAccess)
• Iniettare in un processo a bassa criticità (es. notepad.exe, come documentato per Rocke)
• Verificare che l'EDR generi alert sia sulla sequenza API sia sul thread remoto
• Confrontare il risultato di pe-sieve con i finding dell'EDR

La detection della PE injection ruota attorno a una sequenza comportamentale ben definita: un processo apre un handle verso un altro, alloca memoria remota, vi scrive un payload ad alta entropia, e infine crea un thread nel contesto del bersaglio. La sfida non è intercettare i singoli eventi — sono comuni anche in operazioni legittime — ma correlare la sequenza intera entro una finestra temporale stretta.

Log source primario: Sysmon. La configurazione deve catturare tre EventID chiave. EventID 10 (ProcessAccess) registra ogni chiamata a OpenProcess con i relativi GrantedAccess mask: un valore come 0x1FFFFF (PROCESS_ALL_ACCESS) verso un processo non figlio è già un segnale forte. EventID 8 (CreateRemoteThread) è il momento culminante della catena — un thread creato da un processo in un altro processo. Infine EventID 1 (ProcessCreate) contestualizza il processo sorgente, permettendo di verificare se la relazione parent-child è anomala.

Il tuning è il punto critico. La detection DET0106 fornita nei dati individua quattro parametri regolabili:

• PayloadEntropyThreshold: soglia di entropia per i blocchi scritti in memoria remota. Un PE compresso o cifrato produce entropia superiore a 7.0 su scala Shannon; il valore consigliato iniziale è 6.8, da abbassare progressivamente in ambienti con basso rumore.
• TargetProcessList: processi ad alto valore che non dovrebbero mai ricevere thread remoti. In base ai dati, i bersagli documentati includono Explorer.exe, WerFault.exe e Notepad.exe — inserirli in una whitelist invertita (qualsiasi thread remoto verso questi processi genera alert) riduce drasticamente i falsi negativi.
• TimeWindow: intervallo massimo tra la scrittura in memoria e la creazione del thread. Un valore di 5 secondi cattura la maggior parte dei framework automatizzati; attori sofisticati possono introdurre delay, ma finestre superiori a 30 secondi generano troppo rumore.
• ParentProcessAnomalyThreshold: filtra le gerarchie di processo legittime (ad esempio, un servizio Windows che crea thread in un proprio processo figlio) dalle sorgenti anomale.

Per i falsi positivi, il nemico principale sono i prodotti di sicurezza stessi: molti AV e DLP utilizzano injection legittime per il loro hooking. La strategia è mantenere una lista di esclusione basata sull'hash del processo sorgente, non sul nome, per evitare masquerading.

Un approccio complementare è il monitoraggio delle API call in userland tramite ETW (Event Tracing for Windows). Il provider Microsoft-Windows-Threat-Intelligence — disponibile con licenza Protected Process Light — logga direttamente le chiamate a VirtualAllocEx e WriteProcessMemory con il contesto del chiamante, offrendo visibilità che Sysmon non può raggiungere senza kernel callback. EDR come Microsoft Defender for Endpoint (a pagamento), Elastic Security (freemium) e Velociraptor (open source) possono consumare questi eventi.

L'analisi post-incidente di una PE injection si concentra quasi interamente sulla memoria volatile e sugli artefatti che il sistema operativo registra come effetto collaterale dell'iniezione. Il disco, per definizione, offre poco: l'intero punto della tecnica è evitare di scrivere il payload su file.

Acquisizione della memoria e analisi con Volatility. Il framework Volatility 3 (open source) è il punto di partenza. Il plugin windows.malfind scansiona le regioni di memoria di ogni processo alla ricerca di pagine con permessi PAGE_EXECUTE_READWRITE che contengono header PE (magic bytes MZ) o shellcode. Per il caso specifico di PE injection, una regione con protezione RWX non backed da un file su disco (cioè il campo File è vuoto nel VAD) è un indicatore forte.

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

Il plugin restituisce indirizzo base, dimensione, permessi e un disassembly preliminare delle prime istruzioni. Da qui si può estrarre il PE iniettato con windows.dumpfiles o con un carve manuale basato sull'offset.

Il plugin windows.threads mostra i thread attivi per processo; un thread il cui indirizzo di start punta a una regione non mappata da un modulo noto è il corrispondente in memoria del CreateRemoteThread osservato da Sysmon in tempo reale. Correlando lo start address del thread sospetto con le regioni individuate da malfind, si costruisce il legame diretto tra iniettore e payload.

Artefatti di supporto sul disco. I log Sysmon, se erano attivi al momento dell'incidente, forniscono timestamp precisi per l'intera catena. EventID 10 registra l'istante esatto dell'accesso al processo target, EventID 8 il momento della creazione del thread remoto. Questi timestamp diventano i cardini della timeline.

Nel contesto della campagna 3CX Supply Chain Attack (C0057), l'uso del tool SigFlip per iniettare codice preservando la firma digitale del file aggiunge un ulteriore artefatto: il PE firmato ha una sezione dati o un overlay anomalo che supera la dimensione attesa. Il tool sigcheck di Sysinternals (gratuito) permette di confrontare la dimensione del file con la dimensione coperta dalla firma Authenticode:

sigcheck.exe -a -h <file_sospetto>

Una discrepanza significativa tra le due dimensioni indica la presenza di dati appendati dopo la firma — tecnica utilizzata per nascondere payload senza invalidare la verifica crittografica.

Per la ricostruzione della timeline completa, il flusso consigliato è: timestamp Sysmon dell'accesso al processo → dump della memoria del processo target → estrazione del PE iniettato → analisi statica del PE estratto (hash, import, stringhe) → correlazione con indicatori noti delle famiglie malware documentate (Carbanak, GreyEnergy, Pikabot, DUSTPAN).

La PE injection è utilizzata trasversalmente sia da gruppi APT nation-state sia da operazioni di crimeware avanzato, con un denominatore comune: la necessità di operare in memoria per evitare la detection basata su file.

Rocke (G0106) è un gruppo orientato al cryptomining che ha integrato la PE injection nel proprio miner TermsHost.exe, iniettandolo in Notepad.exe. La scelta del processo target è significativa: Notepad è quasi sempre presente su un sistema Windows, ha un profilo di attività di rete nullo che non attira l'attenzione, ed è un processo a utente che non richiede privilegi elevati per l'iniezione. Il modello operativo di Rocke dimostra come anche attori motivati finanziariamente adottino tecniche di evasione tipicamente associate a operazioni di spionaggio.

Gorgon Group (G0078) utilizza un approccio a due stadi: il malware iniziale scarica ShiftyBug, un RAT, e lo inietta in un processo separato. Questo pattern di download-and-inject separa la fase di consegna dalla fase di esecuzione persistente, complicando l'attribuzione e la correlazione degli artefatti forensi.

La campagna 3CX Supply Chain Attack (C0057) rappresenta un caso di particolare rilevanza strategica. Condotta tra fine 2022 e marzo 2023, è stata la prima compromissione a catena documentata pubblicamente — un supply chain attack che ne ha innescato un secondo. Il cluster UNC4736, associato ad AppleJeus, ha utilizzato il tool SigFlip per iniettare codice arbitrario in PE firmati senza comprometterne la firma digitale. Questo approccio eleva la PE injection a un livello superiore: non si tratta solo di iniettare in un processo in memoria, ma di pre-iniettare il payload nell'eseguibile distribuito, preservandone l'apparenza di legittimità.

Sul fronte dei tool, l'ecosistema è ampio e in evoluzione. Brute Ratel C4 e Havoc rappresentano la nuova generazione di framework C2 che offrono PE injection nativamente, con target specifici come Explorer.exe e WerFault.exe. Il malware bancario Zeus Panda (S0330) e Carbanak (S0030) dimostrano che la tecnica è un pilastro consolidato del crimeware finanziario. GreyEnergy (S0342), con il suo modulo di iniezione PE remota, collega la tecnica al targeting di infrastrutture critiche.

Un pattern emergente riguarda i processi target scelti: i dati mostrano una preferenza per processi di sistema con alta legittimità percepita — WerFault.exe (usato sia da Havoc che da Pikabot), Explorer.exe (Brute Ratel C4), Notepad.exe (Rocke). L'analista TI dovrebbe monitorare la creazione anomala di thread in questi processi come indicatore di compromissione trasversale a più famiglie malware.

Framework MITRE ATT&CK v16: T1055.002, TA0005, TA0004, G0106, G0078, C0057, S1063, S0260, S1229, S0030, S0681, S1138, S0342, S1158, S1145, S0330, M1040. Detection: DET0106 / AN0297. Integrato con conoscenza professionale per tool e procedure operative.