Payload Strippati: Stripped Payloads (T1027.008)

Dal punto di vista offensivo, lo stripping è un passaggio di post-produzione del payload, non un exploit in sé. Serve a ritardare l'analista, e in laboratorio va simulato per misurare quanto rallenti la vostra detection statica.

Su Linux il comando canonico è strip delle GNU binutils (open source), che rimuove la symbol table e le sezioni di debug: strip --strip-all payload elimina tutti i simboli, mentre strip --strip-debug payload preserva quelli globali togliendo solo le informazioni di debug. A monte, compilando con GCC o Clang, l'assenza del flag -g e l'uso di -s in linking producono direttamente un artefatto già privo di simboli. Per verificare l'effetto si usa file payload (mostra "stripped" vs "not stripped") e nm payload, che restituisce "no symbols" su un binario ripulito.

Su macOS l'equivalente per i Mach-O è strip binary dagli Xcode command line tools, oppure la generazione di run-only AppleScript con osacompile -x -o payload.scpt sorgente.applescript: il flag -x produce uno script eseguibile ma non decompilabile, esattamente la scelta operativa adottata da macOS.OSAMiner (S1048) per cancellare gli indicatori leggibili. Cuckoo Stealer (S1153) rappresenta invece il caso del binario stripped classico.

Su Windows il concetto si traduce nella compilazione in modalità Release senza generazione di file PDB, nella rimozione delle stringhe di debug e nell'assenza di rich header significativi; strumenti di packing e obfuscation completano la rimozione delle stringhe in chiaro.

Una catena d'attacco realistica in laboratorio prevede: sviluppo del payload, compilazione ottimizzata, stripping dei simboli, e infine misura del delta di analisi. Per valutare l'esito lato blue team conviene analizzare l'artefatto con Ghidra (open source) o radare2/rizin (open source): un binario stripped costringe l'analista a lavorare per pattern e riferimenti invece che per nomi di funzione. La misura dell'entropia delle stringhe con strings payload | wc -l e strumenti come DIE - Detect It Easy (open source) evidenzia la povertà informativa. In un red team lab-safe l'obiettivo non è solo evadere, ma documentare quanto la mancanza di simboli aumenta il tempo medio di triage del SOC, così da giustificare investimenti in detection comportamentale.

Per la detection conviene abbandonare l'idea di intercettare lo stripping in sé — è un'operazione offline — e concentrarsi su come e da chi il payload ripulito viene creato, droppato ed eseguito. La strategia DET0019 propone proprio un approccio comportamentale multipiattaforma.

Su Windows (rilevamento AN0055) l'obiettivo sono eseguibili o script privi di informazioni di simbolo e stringhe leggibili, generati o rilasciati da processi anomali o di vita breve. Le fonti sono Sysmon (in particolare l'EventCode 11 per la creazione file e l'EventCode 1 per lo spawn di processo) e la telemetria file dell'EDR. La correlazione chiave è temporale: creazione del file e nascita del processo entro una finestra ristretta. Come indicatore statico, una bassissima entropia di stringhe suggerisce un binario ripulito o offuscato.

Su Linux (AN0056) si osservano file binari creati senza tabella dei simboli o con sezioni stripped, soprattutto se prodotti da shell non interattive o da compilatori invocati fuori dai percorsi di sviluppo standard. Le fonti sono auditd (eventi EXECVE e SYSCALL) e query osquery. Il tuning si basa su combinazioni di flag di stripping, sul confinamento delle directory di output dei compilatori e su soglie dimensionali anomale.

Su macOS (AN0057) il segnale forte è la creazione di run-only AppleScript o Mach-O privi di symbol table, specie se droppati da motori di scripting in user space o da app di staging. Si attinge a unified log, Endpoint Security e osquery, filtrando sul flag run-only, sul processo padre e sullo stato di firma (unsigned vs developer-signed).

A livello di rete (AN0058), i flussi NSM:Flow aiutano a individuare payload binari trasferiti via HTTP/S con header compressi o codificati, Content-Type octet-stream incoerenti o transfer-encoding base64 sospetti.

Come controllo preventivo, l'application allow-listing e la firma del codice riducono la superficie: un binario unsigned e stripped che nasce da un processo di scripting è intrinsecamente più sospetto. I falsi positivi principali derivano da toolchain legittime — build server, compilatori, tool di amministrazione che producono naturalmente binari stripped in Release. Per questo il tuning insiste sul whitelisting dei ParentProcessName dei builder noti e delle directory di compilazione, così da non annegare gli analisti nel rumore delle pipeline di sviluppo.

In fase forense l'artefatto stripped è paradossalmente informativo proprio per ciò che gli manca. Il primo passo è la caratterizzazione statica del file recuperato: la presenza o assenza della symbol table è di per sé un indicatore da annotare in timeline.

Su Linux il comando file distingue immediatamente un binario "stripped" da uno "not stripped", mentre readelf -S elenca le sezioni ELF e rivela l'assenza di .symtab e .debug; nm che risponde "no symbols" conferma la ripulitura. Correlare questi dati con gli eventi auditd (EXECVE e SYSCALL) permette di ricostruire quale processo abbia creato il file e in quale directory, distinguendo un output legittimo di compilatore da un drop anomalo fuori dai percorsi di sviluppo. Le query osquery sulla tabella dei file e dei processi aiutano a fissare i timestamp di creazione.

Su macOS l'attenzione va ai run-only AppleScript: un file .scpt compilato con il flag di esecuzione che impedisce la decompilazione è esattamente il pattern usato da macOS.OSAMiner. Gli artefatti utili provengono dallo unified log, dalla telemetria Endpoint Security e da osquery, incrociando il processo padre (il motore di scripting o l'app di staging) e lo stato di firma del payload. Per i Mach-O, l'assenza di symbol table e di riferimenti a stringhe è il marcatore da documentare.

Su Windows, l'assenza di file PDB associati, di rich header significativi e di stringhe di debug indica una compilazione volutamente impoverita; gli EventCode 11 e 1 di Sysmon ancorano la creazione e l'esecuzione a una finestra temporale precisa, elemento cruciale per la timeline. Il caso di Cuckoo Stealer, distribuito come binario stripped, illustra bene come l'analisi debba spostarsi dai nomi simbolici verso pattern di codice e riferimenti indiretti.

Per l'analisi approfondita del codice residuo si usano Ghidra (open source) e radare2/rizin (open source), che consentono di annotare manualmente funzioni prive di nome, mentre l'estrazione delle poche stringhe superstiti con strings fornisce ancora indicatori di compromissione parziali. È buona pratica calcolare gli hash del campione e conservare l'entropia delle stringhe come attributo forense: una entropia estremamente bassa documenta oggettivamente la natura ripulita del payload e supporta la ricostruzione dell'intento di anti-analisi da parte dell'attaccante.

I dati MITRE per questa tecnica non associano alcun gruppo APT formalmente attribuito, né campagne codificate: lo stripping dei payload è un comportamento trasversale e commoditizzato, adottato indipendentemente da molti attori perché economico e universalmente efficace nel rallentare i difensori. Questo assenza di firma è essa stessa un dato di intelligence: la tecnica non discrimina l'autore, quindi va trattata come un moltiplicatore di stealth più che come un indicatore di attribuzione.

I due riferimenti concreti disponibili sono entrambi software malevolo. macOS.OSAMiner (S1048) è un cryptominer per macOS che ha impiegato run-only AppleScript — versione compilata e stripped di AppleScript — per eliminare gli indicatori leggibili ed evadere l'analisi. Il suo utilizzo di questo formato è significativo perché mostra come la scelta della tecnica sia guidata dalla piattaforma: nell'ecosistema Apple, il run-only è il modo più naturale e nativo per ottenere anti-analisi senza dipendere da packer di terze parti. L'obiettivo tipico di questa famiglia è la persistenza silenziosa per il mining, dove restare non identificati il più a lungo possibile massimizza il profitto.

Cuckoo Stealer (S1153) rappresenta invece il pattern classico del binario stripped su piattaforma desktop, orientato al furto di informazioni. Come infostealer, beneficia della riduzione delle stringhe leggibili per nascondere gli endpoint di esfiltrazione, i nomi delle credenziali cercate e la logica di raccolta, complicando sia la detection statica sia la scrittura di firme.

Sul piano dei pattern, emerge una chiara divergenza per piattaforma: macOS spinge verso i run-only AppleScript nativi, mentre gli ambienti Windows e Linux ricorrono allo stripping della symbol table tramite toolchain standard. Questo overlap di strumenti — l'uso di funzionalità legittime dei compilatori come vettore di anti-analisi — rende difficile separare l'intento malevolo dal normale ciclo di build del software, ed è la ragione per cui la detection deve essere comportamentale e contestuale.

Il trend di fondo, deducibile dalla natura stessa della tecnica, è la crescente adozione di anti-analisi "a costo zero": non richiede exploit né infrastruttura, solo un flag di compilazione. Per un Threat Intelligence Officer questo significa che lo stripping va monitorato come indicatore di maturità operativa dell'avversario piuttosto che come marcatore di identità, integrando l'osservazione con altri elementi della catena per arrivare all'attribuzione.

MITRE ATT&CK: tecnica T1027.008 (Stripped Payloads), tattica TA0005; software S1048 (macOS.OSAMiner) e S1153 (Cuckoo Stealer); strategia di detection DET0019 con analytics AN0055–AN0058. Tool citati per verifica e analisi: GNU binutils (strip, nm), readelf, file, strings, osacompile, Ghidra, radare2/rizin, DIE - Detect It Easy, Sysmon, auditd, osquery. Per comandi, sintassi e procedure operative è stata integrata conoscenza professionale di cybersecurity.