Persistenza via Active Setup: Boot or Logon Autostart Execution - Active Setup (T1547.014)

In un esercizio red team, l'abuso di Active Setup si presta a scenari di persistenza post-exploitation dove si dispone già di privilegi amministrativi locali (via bypass UAC, credential theft o token impersonation). L'operazione richiede una singola scrittura di registro e un file eseguibile sul disco (o un LOLBin che carichi payload in memoria).

La struttura minima è una sottochiave con GUID sotto il percorso Active Setup di HKLM. Da PowerShell elevato:

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components{5A7B0E4F-1D2C-4E3F-9A8B-000000000001}" -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components{5A7B0E4F-1D2C-4E3F-9A8B-000000000001}" -Name "StubPath" -Value "C:\ProgramData\upd\agent.exe" -PropertyType String

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components{5A7B0E4F-1D2C-4E3F-9A8B-000000000001}" -Name "Version" -Value "1,0,0,0" -PropertyType String

È buona prassi impostare anche un valore (Default) che imiti un nome di componente Microsoft, per far apparire la chiave come parte di un update legittimo. Per aumentare la stealth si usa GUID mai visto in baseline aziendale e si punta StubPath a un binario firmato che carica una DLL side-loaded, invece che a un PE grezzo scritto dall'operatore.

Alternativa living-off-the-land, sostituendo il valore StubPath con:

rundll32.exe C:\ProgramData\upd\helper.dll,EntryPoint

oppure con un powershell.exe -w hidden -enc per esecuzione fileless al logon.

Sul fronte tooling, Metasploit Framework (open source) fornisce moduli di persistence generici che possono essere adattati, mentre Empire/Starkiller (open source) include moduli di persistence via registry. Per operazioni più mirate, SharPersist di FireEye/Mandiant (open source) implementa esplicitamente il modulo Active Setup con il flag -t activesetup, gestendo GUID, StubPath e Version in un unico comando. Impacket (open source) permette di eseguire la scrittura remota via reg.py o tramite WMI su host già compromessi.

Per validare la persistenza senza aspettare un logon reale, in laboratorio è sufficiente disconnettere la sessione utente (logoff) e ricollegarsi: se il Version HKLM è superiore a quello HKCU (o quest'ultimo assente), userinit.exe eseguirà lo StubPath. Ricordarsi che l'esecuzione avviene una sola volta per utente finché la Version non viene incrementata: per re-trigger basta bumpare il valore.

La detection di Active Setup ruota attorno a un principio semplice: le chiavi sotto *HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components* cambiano raramente, e ogni scrittura fuori dal contesto di Windows Update o di installer firmati Microsoft merita attenzione.

La telemetria più affidabile arriva da Sysmon (gratuito, Microsoft) con configurazione che includa gli EventID 12 (RegistryEvent - CreateKey), 13 (SetValue) e 14 (RenameKey). Nella policy Sysmon (una base solida è la config di SwiftOnSecurity, open source) va inclusa esplicitamente la regex sul path Active Setup, in particolare filtrando la creazione di sottochiavi GUID e la scrittura del valore StubPath. Il campo Image dell'evento identifica il processo scrivente: qualsiasi valore diverso da TrustedInstaller.exe, msiexec.exe o installer firmati Microsoft è un forte segnale, specie se il chiamante è powershell.exe, reg.exe, cmd.exe o processi office/browser.

In parallelo servono i log Security con auditing del registro abilitato (EventCode 4657 - A registry value was modified) sulla chiave Active Setup impostata come SACL. Questo consente di attribuire la modifica a un SID utente, elemento chiave per capire se la scrittura arriva da un account amministrativo interattivo o da un service account compromesso.

La correlazione più efficace, in linea con la detection AN0871, è multi-evento: scrittura di StubPath seguita entro 5-10 minuti da un logon utente e dall'esecuzione di un processo figlio di userinit.exe il cui path corrisponde al valore appena scritto. Una regola Splunk/Sentinel/Elastic che unisca EventCode 4688 (o Sysmon EventID 1) con ParentImage=userinit.exe e Image non appartenente alla whitelist di componenti Microsoft noti (Internet Explorer setup, .NET, Themes) riduce drasticamente il rumore.

Indicatori aggiuntivi da pesare nella logica:

• StubPath che punta a percorsi non standard (*C:\ProgramData*, *C:\Users\Public*, %TEMP%) invece di *%SystemRoot%\System32*
• Binario referenziato non firmato o firmato con certificato non-Microsoft
• Comando che invoca interpreti (rundll32, powershell, mshta, wscript)
• GUID della sottochiave non presente in una baseline raccolta su golden image

Sui falsi positivi: software enterprise legacy (agent EDR di vecchia generazione, alcuni pacchetti di deployment SCCM, LOB app aziendali) usa ancora Active Setup per initialization per-user. La strategia corretta è costruire una allowlist di GUID e StubPath approvati per l'organizzazione, aggiornata dal team di packaging, e alertare su tutto il resto. Un hunt periodico che confronti l'inventario HKLM Active Setup con il baseline della golden image individua ogni deriva.

Sul disco, il primo target dell'analisi è l'hive SOFTWARE (C:\Windows\System32\config\SOFTWARE), da acquisire live con KAPE (gratuito per uso non commerciale, Kroll) o FTK Imager (gratuito, Exterro) e parsare offline con Registry Explorer di Eric Zimmerman (open source) oppure RegRipper (open source, Harlan Carvey), che dispone di plugin dedicati per enumerare Active Setup.

Il percorso di interesse è *SOFTWARE\Microsoft\Active Setup\Installed Components*. Ogni sottochiave GUID va confrontata con una baseline nota: sistemi Windows 10/11 puliti ne contengono un set ristretto (Internet Explorer, Themes Setup, DirectDrawEx, .NET Framework, Windows Desktop Update). Chiavi con GUID non presenti nella baseline, o con timestamp LastWrite successivo alla data di provisioning della macchina, sono candidate immediate all'analisi. Per ogni chiave sospetta vanno estratti: valore (Default) (nome del componente), StubPath (comando eseguito), Version (usato per il confronto con HKCU), IsInstalled e Locale.

La timeline si costruisce integrando più sorgenti. Il timestamp LastWrite della sottochiave HKLM indica quando la persistenza è stata piantata. Nell'hive NTUSER.DAT di ciascun profilo, la stessa GUID appare sotto *Software\Microsoft\Active Setup\Installed Components* con la Version copiata dopo l'esecuzione: il LastWrite di questa chiave utente marca il momento del primo logon post-persistenza, cioè l'istante in cui il payload è girato. Correlando con il file Amcache.hve (esecuzione binari), i Prefetch in *C:\Windows\Prefetch* e gli eventi 4624/4688 nel Security log, si ricostruisce chi era loggato e quale processo è stato lanciato.

Gli artefatti a supporto includono UserAssist (indica interazione GUI, utile per distinguere esecuzione automatica da manuale), ShimCache/AppCompatCache (traccia esecuzioni anche in assenza di Prefetch), SRUM (C:\Windows\System32\sru\SRUDB.dat, parsabile con srum-dump open source di Mark Baggett) per uso di rete del payload post-esecuzione, e MFT per timestamp di creazione del binario referenziato dallo StubPath.

Lato triage rapido, Autoruns di Sysinternals (gratuito, Microsoft) nella tab Logon include esplicitamente le voci Active Setup e permette di filtrare per Verify Code Signatures e Hide Microsoft Entries, isolando immediatamente le entry non firmate.

Sul fronte casistica documentata, il caso di riferimento è il RAT PoisonIvy (S0012), che stabilisce persistenza creando una chiave Active Setup con StubPath che punta al proprio eseguibile: la presenza di una GUID atipica accoppiata a un binario in path utente o ProgramData con nome mimetizzato è pattern coerente con questa famiglia. Va sempre calcolato l'hash SHA-256 del binario e sottomesso a VirusTotal (freemium) e alle piattaforme di threat intelligence interne per attribuzione.

L'inventario MITRE per T1547.014 non associa gruppi APT specifici, ma documenta un caso rilevante sul piano tooling: il RAT PoisonIvy (S0012), che implementa nativamente la persistenza via Active Setup creando una chiave con StubPath puntante al proprio eseguibile. PoisonIvy è un remote access trojan storicamente diffuso in operazioni di cyber-espionage e ha attraversato molteplici cluster di attività senza essere legato a un singolo attore, elemento che rende Active Setup un indicatore di TTP condivisa più che una firma esclusiva.

Dal punto di vista dell'analista di threat intelligence, l'assenza di attribuzione formale nel dataset MITRE non va letta come segnale di bassa rilevanza. Al contrario, Active Setup è una tecnica di persistenza a basso costo di sviluppo (una scrittura di registro), alta compatibilità (funziona su tutte le versioni Windows moderne senza dipendenze), e bassa detection rate in ambienti dove il monitoring del registro è limitato alle chiavi Run/RunOnce classiche. Questo profilo la rende attraente per un ampio spettro di attori: da commodity malware distribuito via phishing, fino a operatori più sofisticati che la usano come fallback rispetto a meccanismi di persistenza primari (WMI subscription, Scheduled Tasks, service installation).

A livello di tracking, un analista dovrebbe modellare l'uso di Active Setup come secondary indicator all'interno di un cluster di TTP più ampio. La sua comparsa raramente basta ad attribuire, ma combinata con lo strumento eseguito da StubPath (RAT, downloader, backdoor) e con altri artefatti (C2 infrastructure, loader, evasion) consente di popolare il Diamond Model dell'intrusione. Il caso PoisonIvy insegna che tool storicamente attribuiti a specifici cluster (ad esempio operazioni contro difesa e high-tech in Asia negli anni 2010) continuano a essere riciclati in campagne successive con nuova infrastruttura, e la persistenza via Active Setup è uno dei behavioral marker che sopravvive nei fork del codice.

A fini di produzione intelligence, i deliverable utili sono:

• Detection content pack per il SOC con regole basate sulla scrittura anomala di StubPath (vedi sezione SOC), condivisibile via MISP (open source) come oggetto con relazione a sightings interne
• Hunting query ricorrenti sulle EDR aziendali per enumerare le chiavi Active Setup non conformi alla golden image
• Baseline dei componenti Active Setup legittimi aggiornata per ciascuna release Windows in uso, distribuita ai team di packaging e response

Sul piano dei trend, il ritorno di interesse verso persistenze registry-only è coerente con la pressione crescente su meccanismi più noti (Scheduled Tasks e Services sono heavy-monitored dagli EDR moderni). Active Setup, insieme ad altre sottotecniche di T1547, rappresenta la coda lunga della persistenza Windows: poco rumore, poca telemetria di default, spesso ignorata dai playbook di IR che non la includono esplicitamente nelle checklist di eradication.

MITRE ATT&CK: tecnica T1547.014 (Boot or Logon Autostart Execution: Active Setup), tattiche TA0003 e TA0004, software S0012 (PoisonIvy), detection DET0312 con analytic AN0871. Riferimento difensivo MITRE D3FEND per registry monitoring e process lineage analysis. Le sezioni operative su tool (Sysmon, Autoruns, KAPE, Registry Explorer, RegRipper, SharPersist, Empire, Impacket, srum-dump, MISP, VirusTotal) integrano conoscenza professionale di cybersecurity relativa a strumenti reali e documentati pubblicamente, con indicazione del modello di distribuzione.