Moduli Condivisi: Shared Modules (T1129)
Con il termine Shared Modules si indica l'esecuzione di codice malevolo tramite il caricamento di librerie condivise all'interno di processi legittimi. Un modulo condiviso è un file eseguibile che fornisce funzioni riutilizzabili — dalle funzioni personalizzate all'invocazione delle API del sistema operativo (Native API). Gli attaccanti sfruttano questo meccanismo per eseguire payload arbitrari, spesso modularizzando il malware in componenti separati che gestiscono comunicazioni C2 o azioni sull'obiettivo.
Su Linux e macOS il loader può caricare oggetti condivisi da percorsi locali arbitrari: la logica risiede in dlfcn.h, con funzioni come dlopen e dlsym. Sebbene macOS possa eseguire file .so, la pratica comune usa file .dylib. Su Windows il loader può caricare DLL da percorsi locali arbitrari e da percorsi di rete UNC; la funzionalità risiede in NTDLL.dll ed è parte della Native API, richiamata a runtime da funzioni come LoadLibrary.
Questa tecnica appartiene alla tattica TA0002 (Execution), la fase della kill chain in cui l'avversario esegue codice sotto il proprio controllo sul sistema locale o remoto. È raramente un'azione isolata: si combina con altre tattiche per raggiungere obiettivi più ampi, come la ricognizione di rete o l'esfiltrazione. I dati MITRE associano a T1129 1 gruppo APT, ben 21 famiglie di malware e 1 mitigazione, un rapporto che evidenzia quanto questo meccanismo sia pervasivo negli arsenali offensivi pur restando difficile da attribuire a un singolo attore.
Dal punto di vista offensivo, il caricamento di moduli condivisi è un primitivo di esecuzione elegante perché ospita il codice all'interno di un processo attendibile, riducendo la superficie visibile rispetto allo spawn di un nuovo eseguibile. La catena tipica su Windows prevede la scrittura di una DLL in un percorso scrivibile e la sua attivazione tramite LoadLibrary, LoadLibraryExW o attraverso reflective loading direttamente in memoria.
Un pattern classico usa i LOLBin di sistema per delegare il caricamento:
rundll32.exe C:\Users\Public\payload.dll,EntryPoint
regsvr32.exe /s /i C:\Users\Public\payload.dll
In ottica red team, il framework di riferimento è Cobalt Strike (a pagamento) con i suoi Beacon Object File e le funzioni di reflective DLL injection, oppure alternative open source come Sliver (open source) e Metasploit Framework (open source), che supportano payload caricabili in memoria. Per lo sviluppo di loader personalizzati, Donut (open source) genera shellcode da assembly .NET, DLL o EXE, mentre sRDI (open source) converte una DLL in shellcode adatto al reflective loading.
Su Linux la sperimentazione lab-safe passa da dlopen() e dlsym() per caricare un oggetto condiviso da directory temporanee come /tmp o /dev/shm. Un vettore complementare è l'hijack del linker dinamico tramite variabili d'ambiente:
LD_PRELOAD=/tmp/evil.so /usr/bin/target_binary
Questo forza il caricamento della libreria prima di quelle legittime, consentendo l'hooking di funzioni — la stessa logica sfruttata da impianti come Ebury contro OpenSSH.
Su macOS il flusso analogo combina dlopen() per caricare il .dylib, seguito dalla risoluzione dei simboli Objective-C via _objc_getClass() e _objc_msgSend() per invocare i metodi della classe caricata: è precisamente il comportamento osservato in impianti come LightSpy e OSX_OCEANLOTUS.D.
Su ESXi e ambienti ibridi, la ricerca di librerie caricabili da path non standard resta un vettore da valutare durante gli assessment. Per esercitazioni controllate, isolare la macchina in un laboratorio segmentato, firmare i payload di test in modo tracciabile e correlare le proprie azioni con la telemetria generata: l'obiettivo è validare la finestra temporale scrittura-file → caricamento-modulo → traffico C2 che il blue team dovrà rilevare.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo