Software Packing: Obfuscated Files or Information – Software Packing (T1027.002)

La simulazione del software packing in laboratorio è essenziale per testare la capacità di detection degli endpoint. L'obiettivo non è creare malware, ma verificare se la catena difensiva — EDR, antivirus, SIEM — identifica il comportamento di unpacking in memoria.

Il punto di partenza più immediato è UPX (open source), il packer usato da almeno 15 dei gruppi documentati. Un payload di test — anche un semplice eseguibile di Meterpreter generato con msfvenom (open source, parte di Metasploit Framework) — può essere impacchettato con un singolo comando:

upx --best -o packed_payload.exe original_payload.exe

Per verificare che il packing sia effettivo, si può ispezionare l'header con Detect It Easy (open source), uno strumento di analisi statica che identifica packer, compilatori e protettori:

diec packed_payload.exe

L'output indicherà "UPX" come packer, ma nella realtà operativa molti avversari vanno oltre. Per simulare il livello successivo, è utile impiegare Donut (open source), un framework che converte assembly .NET, EXE e DLL in shellcode position-independent, applicando compressione e cifratura. Il comando base per generare un modulo packed:

donut -i payload.exe -o loader.bin -z 2

Il parametro -z 2 applica compressione aPLib. Il risultato è un blob che viene decompresso e mappato in memoria al runtime, replicando esattamente il pattern di molti packer custom documentati nelle campagne.

Per spingersi verso la virtualizzazione del codice — il secondo vettore descritto nella tecnica — strumenti commerciali come Themida (a pagamento) o VMProtect (a pagamento) sono quelli effettivamente usati dai gruppi APT. In ambiente lab, l'alternativa open source pe_to_shellcode (open source) permette di convertire PE in shellcode, testando la detection dell'esecuzione da segmenti di memoria non convenzionali.

La catena d'attacco completa per un red team engagement segue questa sequenza:

1. Generare il payload con msfvenom o un custom implant
2. Applicare il packing con UPX o Donut
3. Testare la detection statica con Detect It Easy e il portale VirusTotal (freemium)
4. Eseguire il payload sull'endpoint monitorato e verificare gli alert Sysmon
5. Iterare con packer diversi per mappare i gap di detection

Una nota operativa importante: APT38 ha usato simultaneamente Themida, Enigma, VMProtect e Obsidium, alternando packer tra campagne diverse. Replicare questa varietà in laboratorio è fondamentale per garantire che le regole di detection non siano ancogate a un singolo packer.

Il packing è progettato per eludere la detection statica: cercare la firma di UPX nell'header PE è utile ma insufficiente, perché un avversario minimamente sofisticato modifica o rimuove le signature del packer. La detection efficace è comportamentale e si concentra su cosa accade quando il payload si decomprime in memoria.

La log source primaria su Windows è Sysmon, in particolare gli eventi legati all'allocazione di memoria e al caricamento di immagini. L'analisi AN0066 documentata per questa tecnica monitora il pattern: allocazione di memoria virtuale anomala → scrittura di codice eseguibile nella regione allocata → esecuzione da sezioni non-image. In pratica, un processo che chiama VirtualAlloc con protezione PAGE_EXECUTE_READWRITE su blocchi insolitamente grandi è un indicatore ad alta fedeltà. Sysmon EventCode 8 (CreateRemoteThread) ed EventCode 7 (Image Loaded) forniscono la telemetria necessaria, ma il tuning è cruciale: occorre filtrare per ParentProcessName per circoscrivere le relazioni padre-figlio tipiche dei loader, ed impostare una soglia su AllocationSizeThreshold per escludere le allocazioni legittime di runtime .NET o Java.

Su Linux, l'analisi AN0067 correla l'esecuzione di file ELF con segmenti di memoria scrivibili ad alta entropia e pattern di codice auto-modificante. La sorgente dati è auditd con regole sulle syscall mmap, mprotect e execve. Il parametro EntropyThreshold va calibrato: valori superiori a 7.0 su scala Shannon indicano quasi certamente contenuto compresso o cifrato. Il parametro TimeWindow consente di correlare la scrittura di un file su disco con la sua esecuzione entro un intervallo ristretto, un pattern comune nei dropper che scrivono il payload unpacked in /tmp o /dev/shm.

Su macOS, la detection AN0068 sfrutta i log Unified e Endpoint Security per identificare binari Mach-O packed che si decomprimono in memoria. Il tuning su SignedBinaryContext è particolarmente utile: un binario packed ma firmato è probabilmente legittimo (software protetto commercialmente), mentre un binario packed e non firmato merita investigazione immediata.

Per ridurre i falsi positivi, è consigliabile mantenere una whitelist di packer legittimi usati internamente — molti software commerciali usano Themida o VMProtect per protezione anti-piracy. Strumenti come YARA (open source) permettono di scrivere regole che identificano le firme dei packer noti come primo livello di triage, lasciando l'analisi comportamentale come secondo filtro per i packer custom o sconosciuti.

L'analisi forense di un binario packed richiede un approccio a due stadi: prima l'identificazione del packer e poi l'estrazione del payload originale. Ogni stadio lascia artefatti specifici che contribuiscono alla ricostruzione della timeline.

Il primo artefatto da cercare è il file su disco. L'entropia delle sezioni PE è il segnale più immediato: una sezione .text con entropia superiore a 6.8 è quasi certamente compressa o cifrata. Detect It Easy (open source) e pestudio (freemium) permettono un'analisi rapida dell'header, identificando il packer e le anomalie strutturali. Un file packed con UPX, ad esempio, presenta sezioni denominate UPX0, UPX1 e UPX2 — ma attenzione, gruppi come GALLIUM e ZIRCONIUM hanno usato packer custom che non lasciano queste firme evidenti.

La seconda classe di artefatti riguarda il comportamento in memoria. Quando il payload viene eseguito, il packer stub alloca memoria con permessi RWX (Read-Write-Execute), vi scrive il codice decompresso e trasferisce il controllo. pe-sieve (open source) è lo strumento d'elezione per catturare questo momento: eseguito contro un processo sospetto, identifica le regioni di memoria con codice iniettato o modificato e può dumpare il payload unpacked. Il comando base:

pe-sieve /pid <PID_sospetto> /shellc /dumps

Il dump risultante è il payload originale, analizzabile staticamente. Volatility 3 (open source) è altrettanto utile per l'analisi post-mortem di immagini di memoria, con il plugin malfind che identifica regioni di memoria con permessi anomali:

vol -f memory.dmp windows.malfind

Per la ricostruzione della timeline, i timestamp chiave da correlare sono: la data di creazione del file packed su disco (artefatto $SI e $FN in MFT su NTFS), il momento del primo caricamento registrato in Prefetch (che può rivelare il nome originale del processo), e le voci di Amcache che registrano l'hash SHA1 del binario packed al momento dell'esecuzione.

Su Linux, le campagne di TeamTNT e Rocke — che hanno usato UPX per impacchettare miner e tool — lasciano tracce nei log di auditd e nei file temporanei sotto /tmp o /dev/shm. Il file .bash_history può contenere invocazioni dirette del packer se l'avversario ha operato interattivamente. L'analisi delle stringhe residue con strings sul binario packed può rivelare indicatori del packer usato anche quando le firme nell'header sono state rimosse.

Un caso di studio illuminante è Raindrop, che durante la campagna SolarWinds ha usato un packer custom con compressione LZMA per nascondere un payload Cobalt Strike. L'assenza di firme di packer noti ha reso l'analisi statica iniziale inefficace, e solo l'analisi dinamica in sandbox ha permesso l'estrazione del payload.

Il software packing è un crocevia tattico dove convergono gruppi con motivazioni, risorse e sofisticazione molto diverse. Analizzare la scelta del packer rivela informazioni significative sul profilo dell'avversario.

APT41 rappresenta il caso più emblematico dell'uso strategico del packing. Durante la campagna C0017 (maggio 2021 – febbraio 2022), che ha compromesso almeno sei reti governative statali negli Stati Uniti, il gruppo ha impiegato VMProtect per rallentare il reverse engineering dei binari malevoli. La scelta di VMProtect — un protettore commerciale con virtualizzazione del codice — segnala un avversario che investe risorse nella persistenza e nell'evasione a lungo termine, coerente con obiettivi di esfiltrazione di PII da ambienti governativi.

APT38, il braccio cyber finanziario della Corea del Nord, mostra un pattern diverso ma altrettanto rivelatore: l'uso simultaneo di Themida, Enigma, VMProtect e Obsidium indica una catena di produzione del malware strutturata, con capability di alternare protettori per evitare il fingerprinting da parte dei difensori. Questa varietà suggerisce un team di sviluppo dedicato piuttosto che un singolo operatore.

Sul versante opposto dello spettro di sofisticazione, gruppi come Volt Typhoon e APT29 hanno scelto UPX, un packer open source e facilmente reversibile. Per Volt Typhoon, che ha usato UPX per offuscare il client FRP e l'utility ScanLine, la scelta riflette una filosofia living-off-the-land: strumenti leggeri, ampiamente disponibili, che si confondono con l'attività di sistema legittima. APT39 ha fatto un passo in più, usando UPX per impacchettare una versione modificata di Mimikatz — una combinazione di tool packing e tool customization che complica il triage automatizzato.

La campagna Operation Dream Job (C0022, settembre 2019 – agosto 2020) del Lazarus Group documenta l'uso di Themida per proteggere file .db malevoli, un'indicazione di targeting sofisticato nel settore difesa e aerospaziale. La campagna SharePoint ToolShell Exploitation (C0058, luglio 2025) mostra invece come il packing con UPX venga applicato anche in scenari di exploitation rapida, con payload ransomware come 4L4MD4R impacchettati da attori diversi tra cui Threat Group-3390 e ZIRCONIUM.

Un pattern geografico emerge chiaramente: i gruppi con nexus cinese (APT41, Threat Group-3390, GALLIUM, Aoqin Dragon, Patchwork) prediligono packer commerciali con virtualizzazione del codice (Themida, VMProtect), mentre i gruppi nordcoreani alternano tra packer commerciali (APT38) e soluzioni più leggere (Kimsuky con UPX). I gruppi orientati al cybercrime (TA505, TeamTNT, Rocke) convergono quasi universalmente su UPX, probabilmente per semplicità operativa e per il fatto che il loro modello di business privilegia il volume sull'evasione avanzata.

Il trend evolutivo punta verso packer custom e protezioni ibride. Saint Bear clona assembly .NET e certificati di code signing da software legittimo, combinando packing e impersonation in un'unica catena di evasione. Questa convergenza tra tecniche suggerisce che il packing puro stia diventando un componente di pipeline di obfuscation multi-stadio piuttosto che una misura standalone.

Framework MITRE ATT&CK v16 — T1027.002 (Software Packing), TA0005 (Defense Evasion), M1049 (Antivirus/Antimalware). Campagne: C0017, C0058, C0002, C0005, C0016, C0025, C0022. Tool di detection: Sysmon (Windows), auditd (Linux), Unified Log/Endpoint Security (macOS), YARA, pe-sieve, Detect It Easy, Volatility 3, pestudio. Integrato con conoscenza professionale per tool e procedure operative.