Persistenza via Office Test: Office Application Startup – Office Test (T1137.002)

Riprodurre questa tecnica in laboratorio è sorprendentemente semplice. L'intera catena d'attacco si riduce a due operazioni: compilare una DLL di test e creare la chiave di registro. Nessun privilege escalation richiesto se si opera nel contesto HKCU.

Inizia preparando una DLL minima con un payload benigno. In un ambiente lab puoi usare Visual Studio (freemium) o MinGW (open source) per compilare una DLL che scriva un log su disco al caricamento. La funzione chiave è DllMain con trigger su DLL_PROCESS_ATTACH: quando Office carica la libreria, il codice nel blocco viene eseguito immediatamente.

Per creare la chiave di registro da riga di comando PowerShell:

New-Item -Path "HKCU:\Software\Microsoft\Office test\Special\Perf" -Force

Poi imposta il valore predefinito puntando alla DLL:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office test\Special\Perf" -Name "(Default)" -Value "C:\TestLab\payload.dll"

Da cmd classico, l'equivalente è:

reg add "HKCU\Software\Microsoft\Office test\Special\Perf" /ve /t REG_SZ /d "C:\TestLab\payload.dll" /f

Per la variante globale (richiede privilegi amministrativi), sostituisci HKCU con HKLM. Questa distinzione è fondamentale nel red teaming: la variante HKCU persiste per il singolo utente compromesso, la variante HKLM colpisce tutti gli utenti della macchina.

Apri Word o Excel e verifica che la DLL venga caricata. Con Process Monitor di Sysinternals (gratuito) puoi filtrare per RegQueryValue sull'intero path e osservare il momento esatto in cui Office legge la chiave. Aggiungi un filtro su CreateFile per confermare il caricamento della DLL.

Per il test in contesti più strutturati, Atomic Red Team (open source) fornisce test atomici per questa tecnica che automatizzano creazione e cleanup della chiave. Lo strumento si integra con Invoke-AtomicRedTeam (open source) in PowerShell per esecuzione ripetibile.

Una variante avanzata prevede di posizionare la DLL su una share di rete UNC, simulando un scenario in cui il payload risiede fuori dal filesystem locale — una scelta che complica la forensic e che è coerente con i pattern operativi osservati in campagne reali. Al termine del test, rimuovi sempre la chiave:

Remove-Item -Path "HKCU:\Software\Microsoft\Office test\Special\Perf" -Recurse -Force

Il punto di forza della detection su questa tecnica è la sua specificità. La chiave Office test\Special\Perf non ha motivo di esistere in un ambiente di produzione. Qualsiasi creazione o modifica di questa chiave è, con altissima probabilità, un indicatore di compromissione reale.

La sorgente primaria è Sysmon (open source), in particolare l'EventCode 12 (creazione chiave di registro) e l'EventCode 13 (impostazione valore di registro). Il filtro deve intercettare ogni operazione su path contenenti Office test\Special\Perf sia nel ramo HKCU che HKLM. Un esempio di configurazione Sysmon nel file XML di policy:

Nella sezione RegistryEvent, aggiungi un tag include con condizione TargetObject contains "Office test\Special\Perf". Questo cattura creazione, modifica e cancellazione della chiave. In un SIEM come Splunk (a pagamento) o Elastic Security (freemium), la query diventa un semplice match su stringa nel campo TargetObject.

Il secondo livello di detection riguarda il caricamento della DLL stessa. L'EventCode 7 di Sysmon (Image Loaded) registra ogni DLL caricata da un processo. Correla gli eventi in cui un processo Office (winword.exe, excel.exe, powerpnt.exe, outlook.exe) carica una DLL da percorsi inusuali come %APPDATA%, %TEMP%, directory utente o share UNC. In ambienti dove Office è standardizzato, la baseline delle DLL caricate è relativamente stabile, il che rende questa anomalia molto visibile.

Per la copertura in ambienti Microsoft 365, i log m365:unified e m365:office possono rivelare comportamenti anomali al livello applicativo, anche se la granularità sul caricamento DLL è inferiore rispetto a Sysmon. L'aspetto chiave è verificare che l'auditing Office sia abilitato a livello di tenant.

Come mitigazione proattiva, le regole Attack Surface Reduction (ASR) di Microsoft Defender for Endpoint (a pagamento) possono bloccare la creazione di processi figlio da applicazioni Office e impedire la scrittura di contenuto eseguibile su disco. Queste regole non agiscono direttamente sulla chiave di registro, ma limitano significativamente ciò che la DLL caricata può fare una volta in memoria.

Un controllo aggiuntivo prevede la creazione preventiva della chiave di registro con permessi restrittivi impostati su Read Control, impedendo così la scrittura a utenti non privilegiati. Questo approccio trasforma la mitigazione in una detection: qualsiasi tentativo di modifica genererà un errore di accesso registrabile nei Security Event Log.

I falsi positivi sono estremamente rari. L'unico scenario plausibile riguarda ambienti di sviluppo interni Microsoft o laboratori dove la chiave viene usata per il suo scopo originale di debug. In un normale ambiente enterprise, un alert su questa chiave merita escalation immediata.

L'analisi forense di questa tecnica ruota attorno a tre artefatti principali: la chiave di registro, la DLL referenziata e le tracce di caricamento nei processi Office.

Il primo passo è acquisire l'hive di registro rilevante. Per HKCU, il file si trova in C:\Users\<utente>\NTUSER.DAT; per HKLM, l'hive è C:\Windows\System32\config\SOFTWARE. Con Registry Explorer di Eric Zimmerman (open source) puoi navigare l'hive offline e localizzare la chiave Microsoft\Office test\Special\Perf. Il timestamp LastWriteTime della chiave fornisce il momento esatto della creazione o ultima modifica — un punto di ancoraggio fondamentale per la timeline.

Analizza il valore (Default) della chiave per ottenere il percorso completo della DLL malevola. Se la DLL è ancora presente su disco, acquisisci hash SHA-256, timestamp MACB (Modified, Accessed, Changed, Birth) dal filesystem NTFS e metadata PE (compilazione timestamp, sezioni, import table). Il file $MFT fornisce la data di creazione originale del file anche se i timestamp standard sono stati manipolati, attraverso l'analisi degli attributi $STANDARD_INFORMATION e $FILE_NAME — una discrepanza tra i due è indicatore classico di timestomping.

Per ricostruire quante volte la DLL è stata effettivamente caricata, i log Sysmon (EventCode 7) sono la fonte primaria, ma in loro assenza puoi consultare gli Amcache (C:\Windows\appcompat\Programs\Amcache.hve) e gli Shimcache (nell'hive SYSTEM, chiave AppCompatCache). Entrambi registrano esecuzioni e caricamenti di binari con percorso e timestamp. ShimCacheParser (open source) e AmcacheParser di Eric Zimmerman (open source) sono gli strumenti standard per l'estrazione.

Le Prefetch di Windows (C:\Windows\Prefetch) relative ai processi Office contengono la lista delle DLL caricate durante l'avvio. Esaminando il file .pf di WINWORD.EXE con PECmd (open source), puoi verificare se la DLL malevola compare tra le risorse referenziate e quante volte il processo è stato lanciato dopo la compromissione.

Se la DLL risiede su una share UNC, i log di connessione di rete e gli artefatti delle ShellBag possono rivelare il percorso di rete. In questo caso, correla con i log del file server per identificare quando la DLL è stata depositata e da quale host.

La timeline complessiva dovrebbe collegare: data di creazione della chiave di registro → data di creazione della DLL → primo avvio di un processo Office post-compromissione → eventuali connessioni C2 generate dalla DLL. Questo flusso permette di stabilire la finestra di esposizione e il dwell time dell'attaccante con precisione.

Il panorama degli attori associati a questa tecnica è circoscritto ma significativo. Un solo gruppo è documentato nell'utilizzo di Office Test come meccanismo di persistenza, e il suo profilo operativo offre indicazioni precise per il threat modeling.

APT28 (G0007), attribuito alla Russia e noto anche come Fancy Bear o Sofacy, ha utilizzato la chiave di registro HKCU\Software\Microsoft\Office test\Special\Perf per mantenere persistenza su sistemi compromessi. Questo gruppo è storicamente associato a operazioni di spionaggio contro governi, organizzazioni militari e istituzioni internazionali. La scelta di Office Test come meccanismo di persistenza è coerente con il profilo operativo di APT28: tecniche che privilegiano la discrezione rispetto alla complessità, sfruttando funzionalità native del sistema operativo e di software ubiquitari come Microsoft Office.

La tecnica si presta particolarmente ad ambienti dove Office è installato universamente e dove gli utenti aprono applicazioni Office con frequenza quotidiana, garantendo esecuzione regolare del payload senza necessità di trigger esterni. Questo la rende ideale per operazioni di raccolta informazioni a lungo termine, dove il dwell time si misura in settimane o mesi.

Dal punto di vista dell'analisi dei pattern, Office Test rappresenta un'alternativa più discreta rispetto ad altri meccanismi di persistenza Office come le macro in template globali o i COM add-in. Non genera avvisi macro, non richiede abilitazione di contenuto attivo da parte dell'utente e non compare nelle interfacce di gestione add-in di Office. Questo la rende particolarmente insidiosa in organizzazioni che hanno investito nella protezione anti-macro ma non monitorano le chiavi di registro Office.

Per le organizzazioni nel mirino di attori state-sponsored con focus su spionaggio geopolitico, l'inclusione di questa tecnica nel threat model è prioritaria. L'assenza di software specifico catalogato suggerisce che la DLL caricata varia da operazione a operazione, rendendo la detection basata su IoC statici poco efficace e rafforzando la necessità di un approccio comportamentale centrato sulla chiave di registro stessa.

Il consiglio operativo per il TI team è monitorare l'evoluzione delle varianti: con l'adozione crescente di Office 365 e delle versioni Click-to-Run, la struttura dei path di registro potrebbe cambiare, e nuovi percorsi equivalenti potrebbero emergere come vettori analoghi.

Framework MITRE ATT&CK v16 — Tecnica T1137.002 (Office Application Startup: Office Test), Tattica TA0003 (Persistence), Gruppo G0007 (APT28), Mitigazioni M1054, M1040, Detection DET0315 (AN0880, AN0881). Tool di detection: Sysmon, Registry Explorer, AmcacheParser, ShimCacheParser, PECmd, ProcMon, Atomic Red Team. Integrato con conoscenza professionale per tool e procedure operative.