Hijack del Profiler .NET: COR_PROFILER (T1574.012)

Il cuore di questa tecnica sta nell'impostare tre variabili d'ambiente — COR_ENABLE_PROFILING, COR_PROFILER e COR_PROFILER_PATH — in modo che ogni processo .NET che si avvia carichi una DLL controllata dall'attaccante. La simulazione in laboratorio è relativamente semplice e non richiede tool complessi.

Il primo passo è preparare una DLL di test. Un approccio classico consiste nel compilare una DLL con un payload benigno (un semplice pop-up o un log su file) che implementi l'interfaccia ICorProfilerCallback. Per un test rapido si può usare una DLL generata con msfvenom (open source, parte di Metasploit Framework):

msfvenom -p windows/x64/messagebox TEXT="COR_PROFILER test" -f dll -o profiler_test.dll

Per impostare la persistenza a livello utente via Registry, si utilizzano comandi Windows nativi:

reg add "HKCU\Environment" /v COR_ENABLE_PROFILING /t REG_SZ /d 1 /f

reg add "HKCU\Environment" /v COR_PROFILER /t REG_SZ /d {CLSID-GUID-personalizzato} /f

reg add "HKCU\Environment" /v COR_PROFILER_PATH /t REG_SZ /d C:\Test\profiler_test.dll /f

Dopo un logoff/logon, qualsiasi processo .NET dell'utente caricherà la DLL specificata. Per testare immediatamente senza riavvio, è possibile impostare le variabili a livello di processo e lanciare un binario .NET:

set COR_ENABLE_PROFILING=1 set COR_PROFILER={CLSID-GUID-personalizzato} set COR_PROFILER_PATH=C:\Test\profiler_test.dll powershell.exe -Command "Write-Host test"

PowerShell, essendo un processo .NET, caricherà la DLL di profiling. A livello sistema — scenario più aggressivo — la scrittura va fatta sotto HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, operazione che richiede privilegi amministrativi e impatta tutti gli utenti.

Per lo scenario di privilege escalation, il test consiste nell'impostare le variabili d'ambiente e attendere che un processo .NET con privilegi elevati (ad esempio un servizio Windows basato su .NET) carichi la DLL. Il tool Process Monitor (gratuito, parte di Sysinternals) è ideale per verificare in tempo reale quale processo carica la DLL e con quali privilegi.

Il cleanup è fondamentale: rimuovere le tre chiavi Registry e la DLL dal disco al termine del test. Per la reportistica, documentare il CLSID utilizzato, i processi .NET che hanno caricato la DLL e il livello di privilegio ottenuto.

La detection di COR_PROFILER si gioca su due superfici: le modifiche al Registry (o alle variabili d'ambiente) e il caricamento anomalo di DLL non gestite nei processi .NET. La strategia raccomandata combina log di Sysmon (open source) con i log di Security nativi di Windows.

Il primo indicatore è la scrittura nelle chiavi Registry associate. Sysmon con EventCode 13 (Registry Value Set) cattura ogni modifica: il filtro deve intercettare i valori COR_ENABLE_PROFILING, COR_PROFILER e COR_PROFILER_PATH sotto i path HKCU\Environment, HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment e sotto eventuali chiavi CLSID in HKLM\SOFTWARE\Classes\CLSID. Una regola Sysmon efficace filtra su TargetObject contenente queste stringhe.

Il secondo indicatore riguarda il caricamento della DLL di profiling. Sysmon EventCode 7 (Image Loaded) registra ogni DLL caricata da un processo: la correlazione tra un processo .NET (come powershell.exe, csc.exe, msbuild.exe o qualsiasi eseguibile managed) e una DLL caricata da un path insolito — ad esempio %TEMP%, %APPDATA% o directory world-writable — è fortemente sospetta.

Per la correlazione temporale, il parametro di tuning TimeWindow è cruciale: una modifica Registry alle variabili COR_PROFILER seguita entro pochi minuti dal caricamento di una DLL non nota in un processo .NET è un segnale ad alta fedeltà.

I falsi positivi principali provengono da ambienti di sviluppo. Visual Studio, profiler commerciali come JetBrains dotTrace (a pagamento) e tool APM come New Relic .NET Agent (freemium) impostano legittimamente queste variabili. Il tuning richiede una whitelist basata su:

• CLSID noti: i GUID dei profiler autorizzati nell'organizzazione
• Path legittimi: directory di installazione dei tool di sviluppo e monitoring
• Processi attesi: Visual Studio, agenti APM, build server

Sui Windows Security Log, EventCode 4657 (audit della modifica Registry) fornisce un secondo canale di detection se l'auditing è abilitato sulle chiavi pertinenti con il comando auditpol /set /subcategory:"Registry" /success:enable /failure:enable. Questo dato indipendente da Sysmon consente correlazione cross-source.

L'analisi forense di un attacco COR_PROFILER ruota attorno a tre classi di artefatti: le modifiche al Registry, la DLL malevola su disco e le tracce del suo caricamento nei processi .NET.

Il punto di partenza è il Registry. Sui sistemi offline, l'analista deve estrarre e analizzare gli hive NTUSER.DAT (per lo scope utente) e SYSTEM (per lo scope macchina). Il tool RegRipper (open source) consente di enumerare rapidamente le chiavi sotto Environment:

rip.pl -r NTUSER.DAT -p environment

Cercare la presenza dei valori COR_ENABLE_PROFILING, COR_PROFILER e COR_PROFILER_PATH. Il timestamp dell'ultima modifica della chiave Environment fornisce il momento dell'impianto della persistenza. Per lo scope sistema, lo stesso controllo va eseguito sull'hive SYSTEM, analizzando ControlSet001\Control\Session Manager\Environment.

Se l'attaccante ha registrato un oggetto COM per la DLL profiler, la chiave CLSID sotto HKLM\SOFTWARE\Classes\CLSID\{GUID}\InprocServer32 conterrà il path della DLL. ShimCacheParser (open source) e l'analisi dell'AmCache tramite Eric Zimmerman's AmcacheParser (open source) possono confermare l'esecuzione della DLL e fornire timestamp aggiuntivi.

La DLL stessa è l'artefatto più prezioso. Una volta identificato il path dal Registry, l'analista deve acquisirne l'hash e confrontarlo con servizi di threat intelligence come il portale VirusTotal (freemium). L'analisi statica con PEStudio (gratuito) rivela se la DLL esporta le funzioni tipiche di un profiler CLR (come DllGetClassObject) o se contiene anomalie — sezioni con entropia elevata, import sospetti da kernel32.dll per injection, o stringhe offuscate.

Per la timeline dei caricamenti, i log Sysmon EventCode 7 sono la fonte primaria: ogni istanza di caricamento della DLL profiler in un processo .NET viene registrata con timestamp, PID e immagine del processo host. In assenza di Sysmon, gli ETW (Event Tracing for Windows) del provider .NET CLR registrano gli eventi di attach del profiler — recuperabili da eventlog file .evtx con path Microsoft-Windows-DotNETRuntime.

Il caso Blue Mockingbird è esemplificativo: il gruppo ha usato wmic.exe per impostare le variabili d'ambiente, il che lascia tracce addizionali nei log di creazione processo (EventCode 4688 o Sysmon EventCode 1) con command line contenente riferimenti a COR_PROFILER. Queste command line nei log di processo sono correlabili temporalmente con la prima apparizione della DLL nella ShimCache, costruendo una sequenza solida: esecuzione di wmic → modifica Registry → caricamento DLL al prossimo avvio di processo .NET.

Il panorama degli attori che sfruttano COR_PROFILER è circoscritto ma significativo per i pattern che rivela.

Blue Mockingbird (G0108) è il gruppo documentato che ha operazionalizzato questa tecnica. Il loro modus operandi prevede l'uso di wmic.exe insieme a modifiche dirette al Registry di Windows per impostare le variabili COR_PROFILER a livello di sistema o utente. L'obiettivo primario del gruppo è il cryptomining: la persistenza tramite COR_PROFILER garantisce che il payload venga ricaricato ogni volta che un qualsiasi processo .NET si avvia, rendendo la rimozione particolarmente difficile se l'operatore difensivo non conosce il meccanismo. La scelta di wmic.exe come vettore di configurazione è tatticamente interessante perché il binario è un LOLBin (Living Off the Land Binary) già presente nel sistema, evitando la necessità di trasferire tool aggiuntivi.

Sul fronte del software, DarkTortilla (S1066) adotta un approccio complementare: invece di abusare di COR_PROFILER per iniettarsi, verifica se COR_ENABLE_PROFILING è attiva come tecnica anti-analisi. Se rileva un profiler attivo, assume di trovarsi in un ambiente di analisi dinamica e modifica il proprio comportamento. Questo pattern è indicativo di una consapevolezza crescente tra i malware developer riguardo all'ecosistema di profiling .NET, sia come vettore offensivo sia come indicatore di sandbox.

Dal punto di vista dei pattern, la tecnica presenta un profilo specifico: richiede accesso iniziale già ottenuto (non è un vettore di ingresso), si presta particolarmente ad ambienti server-heavy con numerosi servizi .NET, e offre un rapporto costo-beneficio elevato perché un singolo impianto nel Registry impatta potenzialmente decine di processi. Il fatto che dal .NET Framework 4 la registrazione COM non sia più necessaria abbassa ulteriormente la complessità operativa.

Le tre mitigazioni documentate — Restrict Registry Permissions (M1024), Execution Prevention (M1038) e User Account Management (M1018) — suggeriscono che la difesa efficace è stratificata: proteggere le chiavi Registry critiche, bloccare DLL non autorizzate tramite application control come AppLocker o WDAC, e limitare i privilegi degli account che possono modificare variabili d'ambiente di sistema. Per il threat intelligence, il consiglio operativo è monitorare la convergenza: se un attore dimostra familiarità con il .NET CLR e opera in ambienti Windows enterprise, COR_PROFILER rientra nel set di tecniche probabili per la persistenza post-compromissione.

Framework MITRE ATT&CK v16 — Tecnica T1574.012 (COR_PROFILER), Gruppo G0108, Software S1066, Mitigazioni M1024/M1038/M1018, Detection DET0479/AN1319. Integrato con conoscenza professionale per tool e procedure operative.