Dirottamento AppDomainManager: Hijack Execution Flow via AppDomainManager (T1574.014)

La simulazione controllata di T1574.014 parte dalla comprensione della catena: il CLR .NET, all'avvio di un processo host, legge il file <eseguibile>.exe.config e cerca gli attributi appDomainManagerAssembly e appDomainManagerType dentro il tag <runtime>. Se questi puntano a un assembly presente nella GAC o nella directory dell'eseguibile, il CLR lo carica prima del codice legittimo.

In laboratorio, la procedura standard per un red team prevede tre fasi. Prima, la creazione dell'assembly malevolo: un progetto Class Library in C# che eredita da AppDomainManager e sovrascrive InitializeNewDomain, dove viene collocato il payload (una reverse shell, uno spawn di Cobalt Strike — a pagamento — o un beacon di Sliver, open source). L'assembly va firmato con strong name tramite sn -k key.snk e compilato con la key referenziata, requisito per il caricamento come AppDomainManager.

Seconda fase: il deployment. L'assembly firmato viene registrato nella Global Assembly Cache con gacutil /i MyManager.dll (richiede Visual Studio SDK, open source per la Community Edition) oppure copiato nella stessa directory dell'eseguibile bersaglio. Poi si crea il file .config accanto al binario target — un buon candidato per i test è PresentationHost.exe o un'applicazione custom .NET — con il blocco XML che dichiara appDomainManagerAssembly puntando all'assembly ostile e appDomainManagerType al nome completo della classe.

Terza fase: l'esecuzione. Basta lanciare il binario legittimo per triggerare il caricamento. In alternativa, si possono impostare le variabili d'ambiente APPDOMAIN_MANAGER_ASM e APPDOMAIN_MANAGER_TYPE a livello utente o macchina tramite setx, per un effetto persistente che si attiva a ogni esecuzione .NET.

Per l'automazione offensiva esistono framework come NetLoader (open source) e i moduli di Covenant (open source, in manutenzione limitata) che facilitano la generazione dell'assembly e del config. Il progetto Donut (open source) è utile per convertire payload arbitrari in shellcode caricabile da un AppDomainManager custom.

Per validare l'efficacia in un engagement, il red team dovrebbe testare processi host diversi: eseguibili Microsoft firmati come msbuild.exe, applicazioni di terze parti in Program Files, e servizi che girano come SYSTEM. La verifica finale avviene osservando il caricamento del modulo tramite Process Explorer (gratuito, Sysinternals) o API Monitor (gratuito), confermando che l'assembly appare nello spazio del processo firmato.

La detection di T1574.014 richiede di correlare tre segnali distinti che, isolati, appaiono benigni: modifiche a file di configurazione, caricamento di moduli .NET non standard, e alterazione di variabili d'ambiente rilevanti per il CLR.

Le fonti primarie sono WinEventLog:Security e WinEventLog:Sysmon. Da Sysmon, gli EventID più significativi sono l'EventID 7 (Image Loaded), che rivela quando un assembly non firmato o firmato da autore inatteso viene caricato dentro un processo .NET host; l'EventID 11 (FileCreate) e EventID 2 (FileCreateTime), utili per intercettare la creazione o modifica di file .exe.config in directory di applicazioni; e l'EventID 13 (RegistryValueSet) per monitorare eventuali modifiche a chiavi di ambiente.

La strategia di detection DET0517 raccomanda di focalizzare il monitoraggio sui processi host .NET più frequentemente abusati: powershell.exe, w3wp.exe, svchost.exe, ai quali conviene aggiungere msbuild.exe, installutil.exe e le applicazioni custom aziendali basate su .NET. Il tuning richiede una whitelist di assembly benigni attesi (parametro AssemblyWhitelist) e una lista di path di configurazione monitorati (ConfigFilePaths), tipicamente le directory di installazione applicativa, system32 e Program Files.

La correlazione temporale è cruciale: un alert ad alta confidenza si genera quando entro una finestra breve (parametro TimeWindow, tipicamente 5-15 minuti) si osservano nell'ordine una scrittura su un file .config seguita dall'esecuzione del binario associato e dal caricamento di un modulo non presente nella whitelist. Una regola Sigma efficace filtra Image ending with .exe.config nel campo TargetFilename di Sysmon EventID 11, escludendo i path noti di update legittimi (Windows Update, installer MSI firmati).

Un secondo livello di detection guarda alle variabili d'ambiente: EventID 4657 del canale Security registra modifiche al registro, e le chiavi HKCU\Environment e HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment vanno monitorate per l'introduzione di nomi come APPDOMAIN_MANAGER_ASM.

I falsi positivi principali derivano da software enterprise legittimo che usa AppDomainManager per scenari validi (alcuni prodotti antivirus, framework di logging come NLog open source, ORM come Entity Framework open source in configurazioni particolari) e da aggiornamenti applicativi che riscrivono file .config. La mitigazione consiste nel baseline period di almeno due settimane per costruire la whitelist e nell'esclusione dei processi di update firmati.

Sul fronte preventivo, la mitigazione M1022 (Restrict File and Directory Permissions) impone di installare applicazioni .NET in percorsi write-protected e di applicare ACL restrittive tramite icacls sui path di risorse, così da impedire la scrittura di file .config da parte di utenti non privilegiati.

L'analisi forense di T1574.014 si sviluppa attorno a tre categorie di artefatti: file di configurazione modificati, tracce di caricamento assembly, e persistenza in registro o variabili d'ambiente.

Il primo artefatto da acquisire è il file .exe.config del binario sospetto. La presenza di un blocco <runtime> con attributi appDomainManagerAssembly e appDomainManagerType in un'applicazione che nativamente non li usa è un indicatore forte. La MFT (Master File Table) del volume NTFS, estraibile con MFTECmd (open source, di Eric Zimmerman), fornisce i timestamp $STANDARD_INFORMATION e $FILE_NAME della modifica: la comparazione tra i due può rivelare timestomping, tecnica spesso abbinata al dirottamento per mimetizzare il file config con date coerenti al binario originale.

La timeline va costruita con Plaso/log2timeline (open source), aggregando MFT, USN Journal, Prefetch e event log. L'USN Journal, parsabile con MFTECmd stesso, mantiene traccia delle scritture recenti anche quando il file è stato successivamente ripristinato o cancellato. I file Prefetch in C:\Windows\Prefetch documentano l'esecuzione del processo host dirottato: l'analisi con PECmd (open source) rivela i file toccati durante l'avvio, e la presenza dell'assembly malevolo tra questi conferma il caricamento.

Sul fronte memoria, un'acquisizione con WinPmem (open source) o Magnet RAM Capture (gratuito) permette l'analisi con Volatility 3 (open source). I plugin windows.dlllist e windows.ldrmodules elencano i moduli caricati nel processo host: un assembly non presente sul disco (memory-only) o presente in path atipici emerge dal confronto. Il plugin windows.malfind può individuare regioni di memoria eseguibili non mappate a file, tipiche di payload iniettati dall'AppDomainManager custom.

Le variabili d'ambiente persistenti si recuperano dagli hive di registro. Il file NTUSER.DAT dell'utente compromesso contiene la chiave Environment, mentre SYSTEM contiene le variabili di sistema. Registry Explorer (open source, Zimmerman) o RegRipper (open source) estraggono i valori: la presenza di COMPLUS_* o variabili con nomi riferiti ad AppDomainManager va investigata.

Gli event log di Windows completano la ricostruzione. Il canale Microsoft-Windows-Application-Experience/Program-Inventory traccia storicamente le installazioni, mentre Microsoft-Windows-DotNETRuntime può registrare errori di caricamento assembly utili a mappare tentativi falliti. Il log Sysmon archiviato, se presente, è la fonte più ricca: EventID 7 con ImageLoaded contenente path atipici, ed EventID 11 con TargetFilename *.exe.config sono le query prioritarie.

La correlazione con l'attività di rete, tramite log del proxy o dei DNS resolver, chiude la timeline collegando il caricamento dell'assembly al C2 successivo, elemento che nel caso di IMAPLoader (S1152) usa protocollo IMAP per il command and control.

Il quadro di intelligence su T1574.014 è oggi ristretto ma significativo. I dati MITRE ATT&CK associano alla tecnica un singolo software documentato, IMAPLoader (S1152), un malware che sfrutta esplicitamente l'AppDomainManager injection come vettore di esecuzione. IMAPLoader è caratterizzato dall'uso del protocollo IMAP come canale di command and control, una scelta che gli consente di mimetizzare il traffico C2 dentro sessioni verso provider di posta legittimi, complicando la detection basata su reputazione dei domini.

L'assenza di gruppi APT formalmente attribuiti nel dataset non implica scarso interesse offensivo: al contrario, T1574.014 è una tecnica di adozione recente nel framework ATT&CK, e la sua caratteristica di far eseguire codice ostile dentro processi firmati Microsoft la rende particolarmente attrattiva per operazioni dove la Defense Evasion (TA0005) è prioritaria. Il pattern d'uso osservato con IMAPLoader — loader modulare che scarica payload di seconda fase — è tipico di catene d'attacco che privilegiano modularità e resilienza rispetto a impianti monolitici.

Dal punto di vista tattico, la triplice classificazione della tecnica (Persistence, Privilege Escalation, Defense Evasion) segnala che gli attori la impiegano trasversalmente lungo la kill chain. La persistenza tramite modifica di file .config è particolarmente efficace in ambienti dove le applicazioni .NET vengono lanciate periodicamente da scheduled task o servizi: ogni avvio ricarica il payload senza bisogno di ulteriori azioni. L'escalation è opportunistica: se il processo host gira come SYSTEM o come service account privilegiato, l'assembly ostile ne eredita il contesto.

Il trend di adozione è coerente con la crescita generale delle tecniche di living-off-the-land nel panorama .NET, dove strumenti come PowerShell, MSBuild e InstallUtil sono già ampiamente abusati. AppDomainManager si posiziona come evoluzione più sofisticata perché non richiede interpretazione di codice testuale (script) ma esegue direttamente assembly compilati, riducendo la superficie di detection tramite AMSI e script block logging.

Per un TI officer, gli indicatori strategici da monitorare sono: la comparsa di IMAPLoader in report di vendor sulla filiera di attacco (particolarmente in campagne di credential harvesting e initial access), l'adozione della tecnica in framework offensivi open source come NetLoader, e menzioni in advisory di CERT nazionali. Il proliferare di POC pubblici su GitHub relativi ad AppDomainManager injection è un leading indicator della diffusione della tecnica presso attori di livello inferiore rispetto agli APT stato-nazione.

La raccomandazione a supporto della leadership è di considerare T1574.014 come tecnica ad alto potenziale di crescita, prioritizzando investimenti in detection basata su Sysmon e in hardening tramite ACL sulle directory delle applicazioni .NET critiche.

MITRE ATT&CK: tecnica T1574.014, software S1152 (IMAPLoader), mitigazione M1022, strategia di detection DET0517 (analytic AN1433). Framework MITRE D3FEND per il mapping delle contromisure. Per comandi, tool forensi e procedure operative è stata integrata conoscenza professionale verificata su documentazione ufficiale dei rispettivi progetti (Sysinternals, Eric Zimmerman Tools, Volatility Foundation, Sysmon, Plaso).