Moduli Condivisi come Veicolo di Esecuzione: Shared Modules (T1129)

Il caricamento di moduli condivisi è una delle tecniche più naturali da replicare in laboratorio perché si appoggia su API di sistema perfettamente documentate. L'obiettivo dell'esercizio red team è dimostrare che un processo legittimo può caricare una DLL (o un .so) arbitraria e ottenere esecuzione di codice, bypassando eventuali controlli basati su firma o percorso.

Su Windows, il punto di partenza è una DLL custom compilata con un payload benigno (ad esempio un calcolo o una scrittura su file di log). Puoi generarla con msfvenom di Metasploit Framework (open source) per i test di detection:

msfvenom -p windows/x64/messagebox TEXT="T1129 Test" -f dll -o test_module.dll

Per caricarla a runtime come farebbe un malware reale tramite LoadLibrary, è sufficiente un semplice loader in C oppure puoi usare rundll32 dalla riga di comando:

rundll32.exe C:\Users\Public\test_module.dll,EntryPoint

Per simulare il caricamento da percorso UNC — scenario documentato nella tecnica — posiziona la DLL su una share SMB interna al lab e invoca:

rundll32.exe \192.168.1.100\share\test_module.dll,EntryPoint

Un test più sofisticato prevede l'uso di un loader custom che chiami direttamente LoadLibraryExW con flag specifici, replicando il comportamento di malware come Astaroth. Il progetto sRDI — Shellcode Reflective DLL Injection (open source) — permette di convertire una DLL in shellcode per il reflective loading, simulando ciò che PipeMon fa in-the-wild con i propri moduli.

Su Linux, la replica avviene tramite le funzioni dlopen e dlsym. Compila un shared object minimale e caricalo con un programma in C che invochi dlopen("./payload.so", RTLD_LAZY). Per testare lo scenario LD_PRELOAD, che Ebury sfrutta agganciandosi a keyutils.so:

LD_PRELOAD=/tmp/test_hook.so /usr/bin/ssh -V

Questo forza il caricamento della libreria prima di qualsiasi altra, permettendo l'hooking delle funzioni di OpenSSH.

Su macOS, il flusso è analogo ma con .dylib. Il malware OSX_OCEANLOTUS.D e LightSpy usano esattamente dlopen() seguito da dlsym() per caricare moduli di comunicazione C2. Compila un .dylib di test con Xcode o GCC e caricalo con un loader che chiami dlopen("/tmp/test.dylib", RTLD_NOW).

Per ogni test, verifica che i log Sysmon (EventCode 7 per Image Load su Windows), auditd (syscall openat su Linux) e Endpoint Security Framework (macOS) registrino correttamente l'evento. Questo chiude il cerchio tra simulazione offensiva e validazione della detection.

La detection di T1129 non può basarsi sul semplice fatto che un processo carichi una libreria dinamica — accade migliaia di volte al minuto su qualsiasi sistema. La chiave è la correlazione comportamentale: non il singolo evento di caricamento, ma la catena file-write → module-load → attività sospetta in una finestra temporale ristretta.

Su Windows, la sorgente primaria è Sysmon (open source) con EventCode 7 (Image Loaded). L'analisi DET0018 del catalogo suggerisce un approccio a tre stadi. Primo, monitora i caricamenti di DLL da percorsi ad alto rischio — %TEMP%, %APPDATA%, directory utente, path UNC — filtrando con una regex nei parametri di tuning (SuspiciousPathRegex). Secondo, correla con EventCode 11 (File Create) per verificare se la DLL è stata scritta su disco poco prima del caricamento, con una finestra di 0-20 minuti. Terzo, verifica se il processo che ha caricato la DLL stabilisce connessioni di rete in uscita (Sysmon EventCode 3).

Un filtro critico per ridurre i falsi positivi è il campo SignatureStatus: configurare l'alert affinché scatti solo quando il modulo caricato è non firmato o con firma invalida (UnsignedOnly = true). Il log Microsoft-Windows-CodeIntegrity/Operational offre un'ulteriore fonte per validare l'integrità dei moduli.

Per la regola SIEM, la logica correlata si esprime così: se un processo LOLBin (rundll32.exe, regsvr32.exe) o un binario sconosciuto carica una DLL non firmata da un path sospetto, e nei 20 minuti successivi genera traffico di rete verso IP esterni — genera alert ad alta priorità. Imposta un RareSignerThreshold basato sulla frequenza dei signer nel tuo ambiente: un certificato mai visto negli ultimi 30 giorni merita attenzione.

Su Linux, auditd è la sorgente fondamentale. Configura regole per intercettare le syscall openat e mmap su file .so provenienti da /tmp, /dev/shm, /var/tmp o directory home utente. L'analisi AN0053 raccomanda anche il monitoraggio delle variabili d'ambiente LD_PRELOAD, LD_LIBRARY_PATH e LD_AUDIT — un processo che setta queste variabili prima di eseguire un binario di sistema è un indicatore forte, come nel caso di Ebury.

Su macOS, i Unified Log e l'Endpoint Security Framework catturano gli eventi dlopen su .dylib non di sistema. Concentrati sulle directory ~/Library, /tmp e directory nascoste sotto /Users. L'assenza di code-signing valido è il discriminante principale.

Un consiglio operativo sui falsi positivi: le applicazioni legittime che usano plugin (browser, IDE, software di grafica) generano enormi volumi di caricamenti da percorsi non standard. Costruisci una baseline di hash e signer noti nel primo mese e usala come allowlist.

L'analisi forense di un incidente che coinvolge T1129 ruota attorno a un quesito centrale: quale processo ha caricato quale modulo, da dove, e cosa è successo subito dopo. La timeline si costruisce incrociando artefatti di filesystem, log di sistema e tracce di esecuzione.

Su Windows, parti dai log Sysmon se disponibili. L'EventCode 7 registra il percorso completo della DLL caricata, l'hash (SHA256 se configurato), lo stato della firma e il processo che ha effettuato il caricamento. Ordina cronologicamente questi eventi filtrando per DLL non firmati o provenienti da path utente-scrivibili. Correla con EventCode 1 (Process Create) per identificare la catena padre-figlio: spesso il loader è un processo apparentemente innocuo che è stato compromesso.

Se Sysmon non era installato al momento dell'incidente, il registro Microsoft-Windows-CodeIntegrity/Operational può rivelare tentativi di caricare moduli con firma invalida. Amcache e ShimCache offrono tracce storiche di DLL eseguite, anche se non catturano il processo chiamante. Per interrogare lo ShimCache da un'immagine acquisita, usa il tool ShimCacheParser di Mandiant (open source):

python ShimCacheParser.py -i SYSTEM -o shimcache_output.csv

Cerca nel file risultante le DLL sospette per path e timestamp. L'artefatto Amcache (nel file Amcache.hve) fornisce hash SHA1 dei moduli e timestamp di prima esecuzione — analizzabile con AmcacheParser di Eric Zimmerman (open source):

*AmcacheParser.exe -f Amcache.hve --csv C:\output*

Per la ricostruzione del contenuto della DLL, un'analisi con pe-sieve (open source) sul sistema live permette di identificare moduli caricati in memoria che non corrispondono a file legittimi su disco — tecnica usata da BLINDINGCAN e PipeMon per il caricamento reflective.

Su Linux, la priorità è il log auditd. Cerca record di tipo SYSCALL con la syscall openat che puntano a file .so in percorsi temporanei. Il campo exe= indica il processo responsabile. Se il sistema usa LD_PRELOAD injection come Ebury, verifica il file /etc/ld.so.preload e le variabili d'ambiente nei record EXECVE di auditd.

Per RotaJakiro, che usa dlopen() su .so da percorsi locali, controlla le directory di staging comuni (/tmp, /dev/shm) e usa find con filtro per timestamp:

find /tmp /dev/shm -name ".so" -newer /var/log/syslog -ls*

Su macOS, i file .dylib sospetti si cercano in ~/Library, /tmp e directory nascoste. L'Unified Log cattura eventi relativi a dlopen — filtra con il predicato subsystem == "com.apple.dyld" usando il comando log. Per LightSpy e OSX_OCEANLOTUS.D, verifica la presenza di .dylib non firmati combinando codesign -v con l'analisi dei timestamp del filesystem APFS.

La timeline finale deve mostrare la sequenza: creazione/download del modulo → caricamento nel processo ospite → eventuale comunicazione C2 → azioni sull'obiettivo. Ogni passaggio deve essere ancorato a un artefatto con timestamp verificabile.

La tecnica T1129 è adottata da un ecosistema software vastissimo — 21 famiglie malware — ma un solo gruppo APT è formalmente attribuito nel catalogo. Questa asimmetria racconta qualcosa di importante: il caricamento di moduli condivisi è talmente fondamentale e pervasivo che raramente viene attribuito come tecnica distintiva di un gruppo specifico. È piuttosto un building block che attraversa l'intero panorama threat.

Mustang Panda (G0129) è il gruppo con attribuzione diretta. Questo attore, noto per operazioni di spionaggio con focus sul Sud-Est asiatico e l'Europa, utilizza LoadLibrary per caricare DLL come parte della propria catena di esecuzione. L'uso di questa tecnica si inserisce nel suo modus operandi che privilegia il side-loading di DLL e l'abuso di eseguibili legittimi come vettore iniziale.

L'analisi del software associato rivela cluster operativi interessanti. Un primo cluster è quello dei RAT modulari classici: gh0st RAT e Hydraq rappresentano la vecchia guardia del malware modulare, entrambi capaci di caricare DLL in memoria per estendere le proprie funzionalità. Questi tool hanno generato varianti e fork per oltre un decennio.

Un secondo cluster riguarda il malware distruttivo e di sabotaggio: Stuxnet e KillDisk usano LoadLibrary per caricare ed eseguire funzioni da DLL, dimostrando che la tecnica non è esclusiva dello spionaggio ma serve anche operazioni cinetiche e distruttive.

Il terzo cluster è quello del malware cross-platform. LightSpy opera su macOS con dlopen() per caricare moduli .dylib, RotaJakiro fa lo stesso su Linux con file .so, ed Ebury si aggancia a keyutils.so per intercettare credenziali SSH. Questo gruppo segnala un trend in crescita: la modularità non è più un privilegio Windows, ma si estende a tutto lo stack UNIX.

Il quarto raggruppamento è quello dei loader e dropper moderni: Bumblebee, DarkWatchman e Metamorfo rappresentano la generazione attuale di loader commerciali e commodity malware che usano il caricamento dinamico come meccanismo core di esecuzione del payload finale.

Infine, VersaMem introduce un vettore atipico: l'abuso della Java Instrumentation API per modificare codice Java in memoria, estendendo il concetto di "modulo condiviso" oltre le librerie native del sistema operativo verso il runtime applicativo.

La tendenza strategica è chiara: la modularizzazione del malware è in accelerazione. Gli attori passano da monoliti a architetture a plugin dove ogni componente è un modulo caricato a runtime, rendendo l'analisi più complessa e la detection dipendente dalla visibilità sulla catena di caricamento, non sul singolo artefatto.

Framework MITRE ATT&CK v16 — T1129 (Shared Modules), TA0002 (Execution). Mitigazione M1038. Detection DET0018, analisi AN0052/AN0053/AN0054. Tool di detection e analisi: Sysmon, auditd, ShimCacheParser, AmcacheParser, pe-sieve. Integrato con conoscenza professionale per tool e procedure operative.