Codice Spazzatura nei Malware: Junk Code Insertion (T1027.016)

Simulare l'inserimento di junk code in laboratorio è essenziale per validare le capacità di detection del Blue Team. L'obiettivo non è creare malware, ma produrre binari che attivino — o, meglio ancora, non attivino — le regole di rilevamento, verificandone la robustezza.

Il punto di partenza più diretto è lavorare su assembly x86. Con NASM (open source), puoi compilare un sorgente in cui il payload reale è sepolto tra blocchi di NOP e istruzioni irrilevanti. Un semplice file .asm con centinaia di nop prima della syscall write produce un ELF che qualsiasi analista dovrebbe riconoscere, ma che molti tool statici ignoreranno. Compila con:

nasm -f elf64 junktest.asm -o junktest.o && ld junktest.o -o junktest

Per scenari più realistici in ambiente Windows, puoi usare msfvenom (open source, parte di Metasploit Framework) per generare shellcode e poi wrapparlo manualmente in un loader C che include funzioni vuote, chiamate API Windows dummy (come GetTickCount o IsDebuggerPresent senza utilizzarne il risultato) e variabili mai referenziate. Questo replica esattamente il pattern usato da Goopy, dove API legittime vengono intercalate tra le istruzioni reali per confondere il disassemblatore.

Per replicare il pattern di StrelaStealer — che inserisce funzioni matematiche eccessive — scrivi un loader in C/C++ che esegue calcoli trigonometrici in loop prima di decifrare il payload. Visual Studio compilerà queste funzioni come codice legittimo, aumentando l'entropia del binario senza modificare il flusso operativo.

Sul versante .NET, che rispecchia l'approccio di Gamaredon Group, lo strumento ConfuserEx (open source) consente di iniettare dead code in assembly .NET già compilati. Il modulo "Invalid Metadata" e il modulo "Control Flow" producono esattamente il tipo di offuscamento descritto nei dati di threat intelligence.

Per validare l'effetto del padding, analizza i tuoi campioni con Detect It Easy (open source): confronta l'entropia sezione per sezione tra il binario originale e quello offuscato. L'aumento di entropia nella sezione .text è l'indicatore che il Blue Team dovrebbe catturare. In alternativa, pe-bear (open source) offre una vista grafica delle sezioni PE che rende immediatamente visibili i blocchi di padding.

Un test efficace prevede di generare tre varianti dello stesso payload — senza junk code, con NOP padding, con dummy API call — e sottoporle tutte e tre al motore AV dell'ambiente di test. La differenza nei tassi di detection misura direttamente l'efficacia dell'offuscamento.

Rilevare junk code a livello di rete o endpoint non è banale: il codice spazzatura, per definizione, non produce comportamenti malevoli osservabili. La strategia vincente è incrociare anomalie statiche con comportamenti dinamici sospetti, esattamente come descritto nella detection strategy DET0322.

La log source primaria su Windows è Sysmon (gratuito). L'analisi AN0913 si concentra su tre segnali combinati: alta proporzione di opcode 0x90 nel binario, dimensione anomala dell'eseguibile rispetto alla funzionalità osservata, e intervallo breve tra creazione del file e sua esecuzione. Quest'ultimo elemento è cruciale: un binario da 15 MB che appare in %TEMP% e viene eseguito entro pochi secondi dalla scrittura su disco è altamente sospetto, indipendentemente dal suo contenuto.

Configura Sysmon per catturare EventCode 11 (FileCreate) sulle directory temporanee e EventCode 1 (ProcessCreate) con hash SHA256. La correlazione temporale tra i due eventi, con una finestra configurabile (parametro TimeWindow), è il cuore dell'alert. Il tuning del parametro ExecutableSizeThreshold richiede un baseline dell'ambiente: raccogli le dimensioni medie dei binari legittimi nelle stesse directory e imposta la soglia a due deviazioni standard sopra la media.

Su Linux, la detection AN0914 si appoggia ad auditd e monitora i binari ELF scritti su disco con entropia o dimensione anomale, seguiti da esecuzione o scrittura in memoria di processi remoti tramite ptrace. Una regola auditd efficace monitora le syscall execve e ptrace in sequenza ravvicinata:

-a always,exit -F arch=b64 -S execve -F exe=/tmp -k junkcode_exec

Il parametro MemoryWriteTargets permette di restringere il monitoraggio ai casi in cui il processo figlio tenta di iniettare in processi padre o in processi di sistema, riducendo i falsi positivi da strumenti di debugging legittimi.

Su macOS, la detection AN0915 utilizza i log di Endpoint Security Framework per identificare Mach-O binary con padding anomalo nelle directory temporanee, specialmente /tmp/, /private/tmp/ e ~/Library/. Il segnale più affidabile è la combinazione di drop + esecuzione + tentativo di privilege escalation in una finestra temporale ristretta.

I falsi positivi principali provengono da software legittimo con packing aggressivo (installer di giochi, runtime UPX-packed) e da strumenti di sviluppo che producono binari con sezioni di debug oversized. Costruisci una whitelist basata sul signing certificate e sul percorso di origine. La mitigazione Antivirus/Antimalware (M1049) raccomanda esplicitamente l'uso di detection comportamentale piuttosto che analisi statica del codice: è il principio guida per ogni regola che scrivi.

L'analisi forense di un binario con junk code inserito inizia quasi sempre da un artefatto endpoint: un file sospetto in una directory temporanea, un processo con comportamento anomalo, o un alert AV che ha catturato il campione dopo l'esecuzione. L'obiettivo è ricostruire la catena — dall'arrivo del file alla sua esecuzione — e caratterizzare il tipo di offuscamento per attribuirlo a una famiglia nota.

Il primo passo è l'analisi statica del binario. Con pefile (open source, libreria Python), estrai le sezioni dell'eseguibile PE e calcola l'entropia di ciascuna. Un valore di entropia nella sezione .text superiore a 6.5 ma inferiore a 7.5 è tipico di junk code insertion: il codice spazzatura aumenta la casualità, ma meno del packing completo. WastedLocker è un esempio documentato in cui il junk code è inserito specificamente per aumentare l'entropia e nascondere il codice reale.

Per i campioni x86, apri il binario in Ghidra (open source) e cerca pattern ripetitivi: sequenze lunghe di 0x90, blocchi di istruzioni aritmetiche il cui risultato non viene mai utilizzato, o chiamate a funzioni che ritornano immediatamente. ZeroT inserisce dummy API call tra le istruzioni reali — nel disassemblatore questo appare come chiamate a GetLastError, GetTickCount o API simili il cui valore di ritorno non viene mai letto.

Nella timeline forense, l'artefatto critico è la correlazione tra creazione del file e prima esecuzione. Su Windows, incrocia i timestamp MFT ($STANDARD_INFORMATION e $FILE_NAME) con i log Sysmon EventCode 1. Su Linux, i log auditd con la syscall execve forniscono il timestamp di esecuzione, da correlare con i metadati inode del filesystem tramite stat.

Per i campioni .NET offuscati — come quelli usati da Gamaredon Group — lo strumento dnSpy (open source) permette di decompilare l'assembly e identificare visivamente i blocchi di dead code: metodi mai chiamati, variabili assegnate ma mai lette, branch condizionali il cui esito è sempre determinato staticamente.

Un elemento spesso trascurato è la dimensione del binario nel contesto della sua funzionalità. Maze inseriva blocchi enormi di junk code che includevano anche componenti apparentemente legati alla decifrazione di stringhe, rendendo difficile distinguere il padding dal codice operativo. Confronta la dimensione del campione con binari noti della stessa famiglia: una differenza significativa suggerisce varianti con livelli diversi di junk code, utile per tracciare l'evoluzione del builder dell'attaccante.

Infine, preserva l'hash del campione pre e post-deoffuscamento. Strumenti come FLOSS (open source, Mandiant) possono estrarre stringhe offuscate automaticamente, bypassando il junk code per raggiungere le stringhe decodificate a runtime — un passo fondamentale per estrarre IoC utilizzabili come C2, mutex e chiavi di registro.

L'inserimento di junk code è una tecnica trasversale: la adottano gruppi con motivazioni, capacità e aree geografiche molto diverse. Proprio questa eterogeneità la rende un indicatore debole se presa isolatamente, ma un tassello prezioso quando combinata con altre TTP nel profilo comportamentale di un avversario.

FIN7 (G0046), il prolifico gruppo criminale finanziario, utilizza junk code casuale per offuscare i propri malware. L'approccio si inserisce in un arsenale di evasion sofisticato che include macro offuscate, PowerShell obfuscation e abuso di strumenti legittimi. Il junk code in questo contesto serve a proteggere tool personalizzati dall'analisi automatica dei sandbox, guadagnando tempo per il lateral movement.

Gamaredon Group (G0047), legato a operazioni di spionaggio contro l'Ucraina, offusca eseguibili .NET inserendo dead code. La scelta del framework .NET è coerente con il profilo del gruppo, noto per l'uso intensivo di script VBS e payload .NET a basso costo di sviluppo. L'inserimento di junk code nei .NET assembly suggerisce l'uso di obfuscator automatizzati piuttosto che offuscamento manuale.

Kimsuky (G0094), gruppo nordcoreano orientato alla raccolta di intelligence, combina junk code con concatenazione di stringhe nei propri script. Questa doppia tecnica — padding e frammentazione — è particolarmente efficace contro i motori di detection basati su pattern matching, poiché né il junk code né le singole parti delle stringhe concatenate corrispondono a signature note.

APT32 (G0050), noto anche come OceanLotus e legato al Vietnam, inserisce garbage code specificamente per ingannare software anti-malware e ricercatori. Il gruppo è noto per un livello di sofisticazione elevato e per il targeting di aziende private e dissidenti; il junk code è parte di una catena di offuscamento multi-layer.

Mustang Panda (G0129), gruppo cinese specializzato in spionaggio geopolitico, utilizza junk code all'interno di DLL malevole. Questo approccio è coerente con la predilezione del gruppo per il DLL side-loading: il junk code nelle DLL rende più difficile l'analisi statica automatica che potrebbe identificare le funzioni esportate malevole.

Il pattern che emerge è chiaro: il junk code non è mai la sola tecnica di evasion, ma sempre parte di un layering difensivo. Per il threat intelligence, il valore analitico sta nel tipo di junk code più che nella sua presenza: NOP sled, dummy API call, funzioni matematiche o dead branch indicano builder diversi e, potenzialmente, toolchain condivise tra gruppi. La presenza di 14 famiglie malware documentate — da ransomware come Maze e SamSam a stealer come StrelaStealer e spyware come FinFisher — conferma che il junk code è una commodity technique disponibile in toolkit commerciali e open source.

Framework MITRE ATT&CK v16 — Tecnica T1027.016, Tattica TA0005, Mitigazione M1049, Detection DET0322 (AN0913, AN0914, AN0915). Gruppi: G0046, G0047, G0094, G0050, G0129. Software: S0449, S0117, S1183, S0248, S0230, S0453, S0370, S0477, S0612, S0137, S0182, S0666, S0223, S0512. Integrato con conoscenza professionale per tool e procedure operative.