Netsh Helper DLL: Netsh Helper DLL (T1546.007)

In un esercizio red team la registrazione di una helper DLL richiede pochi passaggi ma va sempre eseguita in laboratorio isolato, tipicamente una VM Windows 10/11 non aggiornata con endpoint protection e integrata in un dominio di test.

Il primo passo è preparare la DLL. Si può usare Visual Studio Community (gratuito per uso personale/educational) oppure MinGW-w64 (open source) per compilare una DLL C/C++ che esporti la funzione InitHelperDll, firma richiesta dal contratto Netshell. La documentazione ufficiale Microsoft su Netsh Helper descrive la struttura NETSH_MODULE_ENTRY e le funzioni di callback obbligatorie. Un helper minimale può limitarsi a scrivere un marker su disco o lanciare calc.exe via CreateProcessW per validare la catena.

La registrazione avviene con il comando nativo:

netsh add helper C:\path\to\payload.dll

In alternativa si può scrivere direttamente la chiave di registro con reg add HKLM\SOFTWARE\Microsoft\Netsh /v MyHelper /t REG_SZ /d C:\path\payload.dll. Entrambe le operazioni richiedono privilegi amministrativi. Per triggerare il carico è sufficiente eseguire netsh interface show interface o qualsiasi altro sottocomando.

Per strutturare l'esercizio in modo realistico si possono usare i seguenti tool, tutti open source o gratuiti a scopo di ricerca:

• Atomic Red Team (open source) — contiene test T1546.007 pronti all'uso con payload di riferimento e cleanup automatico
• Metasploit Framework (open source) — modulo exploit/windows/local/persistence_netsh per generare e installare helper DLL Meterpreter
• PowerSploit (open source, archiviato ma funzionante) — funzioni PowerShell per manipolare registry key di persistenza
• Sysinternals Suite (gratuito) — Process Monitor per verificare il caricamento della DLL e Autoruns per confermare la persistenza registrata

Una catena completa parte da un foothold utente standard, procede con un'escalation locale (es. token impersonation da servizio vulnerabile), scrittura della helper DLL in una directory scrivibile ma dall'aspetto legittimo come C:\ProgramData\Vendor\netmon.dll, registrazione nel registro e infine trigger tramite scheduled task che invoca netsh. Documenta ogni step nel report con timestamp, hash della DLL e output di Process Monitor filtrato su netsh.exe.

Per il cleanup: netsh delete helper payload.dll e rimozione manuale del file. Non lasciare mai artefatti nel lab condiviso.

La detection di T1546.007 si costruisce sulla correlazione tra due eventi che, presi isolatamente, generano rumore ma insieme diventano un segnale forte: modifica del registro sotto HKLM\SOFTWARE\Microsoft\Netsh e successivo caricamento anomalo di DLL da parte di netsh.exe. Questa è la logica della detection strategy DET0575 (analytic AN1588) applicata a piattaforma Windows.

Sul fronte delle log source, Sysmon (gratuito, Microsoft Sysinternals) è il pilastro. La configurazione va estesa per catturare:

• Event ID 13 (RegistryEvent Value Set) filtrato su TargetObject che contiene *\Software\Microsoft\Netsh*
• Event ID 7 (Image Loaded) per DLL caricate da netsh.exe al di fuori di *C:\Windows\System32*
• Event ID 1 (ProcessCreate) con ParentImage uguale a netsh.exe per intercettare child process anomali
• Event ID 11 (FileCreate) per DLL scritte in path sospetti poco prima della modifica registry

Dal Security log nativo l'EventCode 4657 fornisce la modifica valore di registro se l'auditing SACL è configurato sulla chiave Netsh, operazione da eseguire preventivamente perché non è attiva di default.

La query di correlazione, esprimibile in KQL su Microsoft Sentinel o SPL su Splunk, deve mettere in join i due eventi entro una finestra di 10 minuti (parametro TimeWindow della detection). Il NetshChildProcessWhitelist va costruito empiricamente osservando l'ambiente per 2-4 settimane: tipicamente include conhost.exe e nulla più. Qualsiasi child process fuori whitelist merita triage immediato. Il parametro DLLLoadPath introduce euristica sui percorsi: helper DLL legittime risiedono in System32, mentre payload malevoli tendono a ProgramData, AppData, Temp o directory create ad hoc.

Sul piano preventivo, l'ipotesi difensiva più efficace consiste nel proteggere la chiave di registro con auditing granulare e nell'applicare policy AppLocker o Windows Defender Application Control per bloccare il caricamento di DLL non firmate da netsh.exe. Microsoft Defender for Endpoint (a pagamento) e le principali EDR commerciali (CrowdStrike Falcon, SentinelOne — a pagamento) hanno rilevatori nativi per questa tecnica basati su image load di DLL non-Microsoft.

I falsi positivi più comuni derivano da client VPN enterprise (Cisco AnyConnect, Palo Alto GlobalProtect) e da software di monitoring di rete che registrano helper legittime. Documentare questi baseline nella whitelist evita alert fatigue. Un secondo scenario benigno sono le utility di configurazione OEM su laptop aziendali, che occasionalmente invocano netsh con moduli proprietari.

L'analisi forense di T1546.007 ruota attorno a tre categorie di artefatti: registro di sistema, filesystem e log di esecuzione. La ricostruzione della timeline richiede il correlamento tra questi tre livelli.

Il primo artefatto è la chiave HKLM\SOFTWARE\Microsoft\Netsh. Su un'immagine acquisita, l'hive SOFTWARE si estrae da C:\Windows\System32\config\SOFTWARE e si analizza con Registry Explorer di Eric Zimmerman (gratuito) o RegRipper (open source). Registry Explorer mostra il LastWriteTime della chiave, che fornisce il timestamp di registrazione dell'helper malevolo. Un valore anomalo — nome sconosciuto, path fuori System32 — è il primo indicatore.

Gli ShellBags, AmCache e ShimCache completano il quadro dell'esecuzione. In particolare AmCache.hve (path C:\Windows\AppCompat\Programs\Amcache.hve) registra hash SHA-1 e path delle DLL caricate, permettendo di identificare la helper DLL anche se successivamente cancellata. AmcacheParser di Zimmerman (gratuito) esporta i dati in CSV pronti per analisi. ShimCache, estraibile con AppCompatCacheParser (gratuito), conferma l'esecuzione di netsh.exe nei momenti sospetti.

Sul filesystem, i Prefetch in C:\Windows\Prefetch\NETSH.EXE-.pf* documentano ogni esecuzione di netsh negli ultimi 128 avvii. PECmd (gratuito, Zimmerman) estrae timestamp di prima e ultima esecuzione, conteggio esecuzioni e — dato cruciale — l'elenco delle DLL caricate durante l'esecuzione. Se compare una DLL con path anomalo, l'attribuzione è quasi certa.

Gli USN Journal e la MFT permettono di ricostruire creazione, modifica e cancellazione della DLL payload. MFTECmd (gratuito) processa entrambi. Un pattern tipico: creazione DLL, modifica registry entro pochi minuti, prima esecuzione di netsh subito dopo, cancellazione della DLL a distanza di ore o giorni (tentativo di anti-forensics).

I log Sysmon storicizzati, se presenti, forniscono la conferma definitiva con Event ID 7 (image load) contenente hash, signer e path della DLL caricata da netsh. In assenza di Sysmon, i log Microsoft-Windows-Kernel-Process possono contenere tracce parziali di process creation.

Per la timeline consolidata, Plaso/log2timeline (open source) aggrega registry, prefetch, MFT ed event log in un supertimeline navigabile con Timeline Explorer (gratuito). L'ordine cronologico tipico è: file drop della DLL, scrittura chiave registry, prima invocazione di netsh (spesso da task pianificato o script di logon), esecuzioni successive periodiche. Documenta hash della DLL in report, correla con VirusTotal (freemium) per attribuzione a famiglie note e preserva l'immagine originale per catena di custodia.

Sul piano della threat intelligence, la tecnica T1546.007 presenta un profilo distintivo: i dati MITRE ATT&CK associati non registrano gruppi APT né campagne pubblicamente attribuite a questa specifica sotto-tecnica, e l'unico software mappato è netsh stesso (S0108), catalogato come tool legittimo abusabile a fini di persistenza proxy.

Questo vuoto attributivo è un dato in sé significativo e merita interpretazione. La tecnica non è nuova — è documentata in ricerca offensiva da oltre un decennio — ma la sua diffusione operativa in campagne tracciate rimane limitata rispetto ad alternative di persistenza più popolari come Scheduled Task (T1053), Registry Run Keys (T1547.001) o WMI Event Subscription (T1546.003). Le ragioni plausibili sono due: da un lato la tecnica richiede lo sviluppo di una DLL conforme al contratto Netshell, uno sforzo di sviluppo non trascurabile rispetto ad alternative script-based; dall'altro la trigger dependency — netsh deve essere effettivamente invocato — la rende meno affidabile di meccanismi con esecuzione garantita al logon o al boot.

Il profilo di adozione tipico è dunque quello dell'attaccante maturo e selettivo che opera in ambienti dove netsh viene invocato frequentemente per ragioni legittime: reti aziendali con client VPN, endpoint gestiti con script di configurazione network, ambienti in cui strumenti di deployment richiamano netsh. In questi contesti la persistenza risulta operativamente affidabile e la telemetria di detection quasi nulla, rendendo la tecnica particolarmente interessante per operazioni di lungo termine e a bassa visibilità.

Dal punto di vista dell'analisi predittiva, gli scenari di threat modeling in cui aspettarsi T1546.007 includono intrusioni con obiettivi di cyber-espionage prolungato, dove la stealth prevale sulla velocità, e compromissioni di ambienti hardened dove le tecniche di persistenza più comuni sono già coperte da EDR baseline. La sovrapposizione con Netsh come Living-off-the-Land Binary (LOLBin) rafforza il posizionamento in playbook che privilegiano l'uso di binari firmati Microsoft per ridurre il rischio di detection basata su firma.

Per un programma di threat intelligence, il monitoraggio andrebbe focalizzato su: report di incident response che citino modifiche alla chiave Netsh, sample condivisi su piattaforme come VirusTotal (freemium) o MalwareBazaar (gratuito, gestito da abuse.ch) con export InitHelperDll, e pubblicazioni di ricerca offensiva che aggiornino la superficie di attacco. L'assenza di attribution consolidata suggerisce cautela nell'assegnare la tecnica a cluster specifici senza evidenze forensi solide.

MITRE ATT&CK: tecnica T1546.007, software S0108 (netsh), detection strategy DET0575 con analytic AN1588. MITRE D3FEND per mapping difensivo su Registry Modification e DLL Load. Documentazione Microsoft ufficiale per Netsh Helper API e struttura InitHelperDll. Parti operative su comandi, tool forensi (Zimmerman tools, Plaso, Sysmon) e procedure di detection integrano conoscenza professionale di cybersecurity verificata su repository pubblici e documentazione ufficiale dei rispettivi progetti.