Hijacking del Dynamic Linker: Dynamic Linker Hijacking (T1574.006)

La simulazione di questa tecnica in laboratorio è sorprendentemente semplice, il che la rende perfetta per dimostrare al cliente quanto sia sottile il confine tra una funzionalità di debug e un vettore di compromissione. Il punto di partenza è la creazione di una shared library malevola che ridefinisce una funzione libc comunemente invocata.

Su un sistema Linux di laboratorio, compila una libreria che intercetta la funzione execve. Il codice C è minimale: una funzione execve che registra la chiamata su file e poi invoca la execve reale tramite dlsym(RTLD_NEXT, "execve"). Compila con:

gcc -shared -fPIC -o /tmp/evil.so evil.c -ldl

A questo punto, la tecnica si biforca in due varianti operative. La prima è la variante per processo singolo, dove imposti la variabile d'ambiente direttamente:

LD_PRELOAD=/tmp/evil.so /usr/bin/ls

La seconda variante è quella persistente a livello di sistema, che replica il comportamento documentato per Rocke e Aquatic Panda: la modifica del file /etc/ld.so.preload. Scrivendo il percorso della libreria in quel file, ogni processo avviato sul sistema caricherà la libreria iniettata senza che la variabile d'ambiente sia visibile nell'environment del processo.

echo "/tmp/evil.so" >> /etc/ld.so.preload

Per simulare lo scenario Ebury — dove l'hooking avviene specificamente sui processi figli di sshd — puoi configurare la variabile LD_PRELOAD all'interno dell'environment del servizio SSH editando il file di unit systemd oppure il profilo di shell caricato dalle sessioni SSH.

Su macOS, la variabile equivalente è DYLD_INSERT_LIBRARIES. Compila un dylib:

clang -dynamiclib -o /tmp/evil.dylib evil.c

E iniettalo con:

DYLD_INSERT_LIBRARIES=/tmp/evil.dylib /Applications/Target.app/Contents/MacOS/Target

Tieni presente che System Integrity Protection (SIP) su macOS ignora queste variabili per i binari protetti, quindi la simulazione funzionerà solo su applicazioni di terze parti che non adottano il Hardened Runtime.

Per il red team è utile il framework Atomic Red Team (open source), che include test specifici per T1574.006 con payload pre-confezionati. Lo strumento linux-inject (open source) su GitHub offre un approccio alternativo basato su ptrace per iniettare .so in processi già in esecuzione, utile per dimostrare la variante runtime rispetto a quella basata su variabili d'ambiente.

Verifica sempre che il laboratorio sia isolato: un /etc/ld.so.preload mal configurato può rendere il sistema inutilizzabile, bloccando qualsiasi esecuzione di binari dinamicamente linkati.

La detection di questa tecnica si gioca su due piani: il monitoraggio delle variabili d'ambiente del linker e la sorveglianza dei file di configurazione che le alimentano. Il primo passo è rendere visibili eventi che normalmente non lo sono.

Su Linux, il framework auditd è il punto di partenza naturale. Configura regole di audit specifiche per intercettare le scritture al file /etc/ld.so.preload e le modifiche ai file di profilo shell dove LD_PRELOAD potrebbe essere esportata:

-w /etc/ld.so.preload -p wa -k dynamic_linker_hijack -w /etc/ld.so.conf -p wa -k dynamic_linker_hijack -w /etc/profile.d/ -p wa -k env_modification

Questi generano eventi auditd:SYSCALL e auditd:PATH che il SIEM può correlare. Il detection AN1209 indica di monitorare specificamente gli eventi execve dove LD_PRELOAD appare nella lista delle variabili d'ambiente. Con osquery (open source) puoi implementare una query schedulata che ispeziona l'environment dei processi in esecuzione:

SELECT pid, name, env FROM process_envs WHERE key = 'LD_PRELOAD';

La correlazione temporale è cruciale. Il parametro di tuning CorrelationWindow definisce la finestra entro cui collegare la creazione di un file .so in una directory non standard — /tmp, home utente, /dev/shm — con l'esecuzione di un processo che lo carica. Una finestra di 60 secondi è un buon punto di partenza; ambienti di sviluppo potrebbero richiedere finestre più ampie o whitelist esplicite.

Per i falsi positivi, il contesto fa la differenza. Ambienti di sviluppo e CI/CD usano legittimamente LD_PRELOAD per strumenti come libfaketime o jemalloc. Il parametro di tuning WatchedEnvVars suggerisce di differenziare i sistemi di produzione da quelli di sviluppo: sulle macchine di produzione, qualsiasi setting di LD_PRELOAD è un segnale ad alta priorità; sulle macchine di sviluppo, correla con la creazione di file .so in path inattesi.

Su macOS, il detection AN1210 sposta il focus su DYLD_INSERT_LIBRARIES e DYLD_LIBRARY_PATH. I Unified Log catturano il caricamento di dylib non previste. Costruisci una baseline delle dylib normalmente caricate dalle applicazioni critiche (parametro BaselineDylibs) e genera alert per ogni deviazione.

Un alert ad alta fedeltà è la combinazione di: scrittura su /etc/ld.so.preload + creazione di .so in path non standard + processo con LD_PRELOAD settato, tutto entro la finestra di correlazione. Questa tripletta ha un tasso di falsi positivi estremamente basso in ambienti di produzione.

L'analisi forense di un dynamic linker hijacking richiede un approccio sistematico che parte dai file di configurazione del linker e risale fino ai processi compromessi. La buona notizia è che questa tecnica lascia artefatti persistenti e relativamente facili da identificare — se sai dove cercare.

Il primo artefatto da esaminare è il file /etc/ld.so.preload. Su un sistema pulito, questo file è tipicamente vuoto o assente. Qualsiasi contenuto merita attenzione immediata. Esamina i timestamp con stat e correla il mtime con gli eventi auditd. Rocke modificava questo file per nascondere il proprio dropper e il software di mining dalle process list, hooking readdir per filtrare i risultati.

Procedi con l'analisi della libreria .so iniettata. I malware documentati seguono un pattern ricorrente: la libreria ridefinisce funzioni libc critiche. Con il comando nm -D o readelf --dyn-syms sul file sospetto, identifica le funzioni esportate. Se trovi ridefinizioni di execve, readdir, open, popen, system — come documentato per Ebury, che hooka ben sette funzioni libc — hai una forte indicazione di hooking malevolo.

readelf --dyn-syms /path/to/suspicious.so | grep -E "execve|readdir|open|popen|system"

Per COATHANGER, cerca specificamente il file /lib/preload.so e tracce del percorso /data2/.bd.key/. Questo malware ha un pattern distintivo: copia la libreria malevola da un path nascosto a /lib/preload.so e la inietta nel processo con PID 1, sostituendo la funzione reboot con una versione malevola chiamata newreboot.

Sulla timeline, ricostruisci la sequenza degli eventi:

1. Creazione del file .so malevolo — cerca con find / -name "*.so" -newer /etc/ld.so.preload per identificare librerie create nello stesso periodo
2. Modifica di ld.so.preload o dei file di profilo shell — verifica /etc/profile, /etc/profile.d/*, ~/.bashrc, ~/.bash_profile
3. Processi che hanno caricato la libreria — su sistemi con auditd attivo, cerca nei log le syscall execve con referenze al file sospetto
4. Attività post-iniezione — i comandi eseguiti sotto hooking sono visibili nei log applicativi ma non in quelli che il malware può filtrare

Su macOS, il file system snapshot di APFS conserva stati precedenti del disco. Verifica le variabili DYLD_INSERT_LIBRARIES e DYLD_FRAMEWORK_PATH nei file .plist di LaunchAgents e LaunchDaemons — XCSSET utilizza specificamente DYLD_FRAMEWORK_PATH e DYLD_LIBRARY_PATH per il caricamento del proprio codice.

Un aspetto insidioso: se il malware hooka readdir e open, i comandi forensi eseguiti sul sistema live compromesso potrebbero restituire risultati filtrati. Per un'analisi affidabile, monta il disco del sistema compromesso su una workstation forense dedicata oppure utilizza un live boot da media esterno.

Il dynamic linker hijacking è una tecnica associata prevalentemente a threat actor con obiettivi finanziari o orientati allo spionaggio che operano in ambienti Linux. I tre gruppi documentati offrono prospettive diverse sulle motivazioni e sulle modalità di impiego.

APT41 è il gruppo più sofisticato del cluster. Attore dual-purpose — spionaggio statale e cybercrime — ha configurato payload per il caricamento via LD_PRELOAD. La scelta di questa tecnica riflette la strategia di APT41 di operare in ambienti dove la visibilità difensiva è storicamente più bassa: server Linux, infrastruttura cloud e sistemi containerizzati. L'uso del dynamic linker hijacking si inserisce in una catena di tecniche che privilegia la persistenza discreta su infrastrutture di lunga durata.

Aquatic Panda ha modificato direttamente il file ld.so.preload per garantire persistenza al malware Winnti in ambienti Linux. La connessione con il malware Winnti — storicamente associato a operazioni di spionaggio industriale con focus sull'Asia-Pacifico e il settore gaming/tecnologico — suggerisce che questa tecnica viene impiegata in operazioni a lungo termine dove la stabilità della persistenza è più importante della velocità di deployment.

Rocke rappresenta il versante cybercriminale puro. L'utilizzo del dynamic linker hijacking per nascondere software di cryptomining è un caso emblematico di come una tecnica di evasione sofisticata venga adottata per proteggere operazioni finanziarie su larga scala. Rocke non si limitava alla persistenza: l'hooking di funzioni libc serviva specificamente a rendere invisibili i processi di mining e il dropper.

Sul fronte malware, la famiglia Ebury merita attenzione particolare per la profondità dell'hooking: sette funzioni libc intercettate (system, popen, execve, execvpe, execv, execvp, execl) consentono un controllo quasi totale sull'esecuzione dei processi figli delle sessioni SSH. COATHANGER è notevole per l'iniezione nel processo con PID 1 — init/systemd — che garantisce una persistenza di livello kernel-adjacent. MEDUSA e Hildegard confermano che questa tecnica è ormai parte del toolkit standard per operazioni su infrastruttura Linux, inclusi ambienti containerizzati.

Il pattern geografico e settoriale emergente indica che il dynamic linker hijacking è una tecnica prediletta per infrastrutture server-side Linux, con una concentrazione su ambienti cloud, hosting provider e organizzazioni con elevata densità di sistemi Unix. L'evoluzione verso ambienti macOS — documentata da XCSSET con le variabili DYLD_FRAMEWORK_PATH — segnala un ampliamento della superficie d'attacco verso endpoint di sviluppatori.

Framework MITRE ATT&CK: tecnica T1574.006 (Dynamic Linker Hijacking), tattiche TA0003, TA0004, TA0005. Gruppi: G0143, G0106, G0096. Software: S0601, S0394, S0658, S1105, S1220, S0377. Mitigazioni: M1028, M1038. Detection: DET0435 (AN1209, AN1210). Integrato con conoscenza professionale per tool e procedure operative.