Una proof of concept chiamata EDR-Freeze dimostra che i componenti di Windows Error Reporting (WER) possono essere usati per mettere in stato di sospensione processi di sicurezza endpoint sfruttando MiniDumpWriteDump e sospendendo il dumper stesso. La tecnica non richiede driver né exploit kernel, ma richiede privilegi elevati e lascia artefatti osservabili che i difensori possono rilevare se la telemetria è adeguata.
EDR-Freeze è una PoC che coordina la creazione di dump tramite il sistema di error reporting di Windows per bloccare l’esecuzione di un agente di sicurezza. Invece di ricorrere a driver vulnerabili o esecuzione in kernel, la PoC utilizza un componente firmato di sistema (WerFaultSecure.exe) insieme a MiniDumpWriteDump per sospendere il processo target e poi sospendere il processo che dovrebbe ripristinarlo, mantenendo quindi l’agente in uno stato di “pausa”. La fattibilità pratica dipende da privilegi sulla macchina e dall’ambiente operativo.

Come funziona l’Exploit
- Selezione del target e privilegi necessari.
L’attaccante deve poter eseguire codice con diritti sufficienti per invocare WER contro un altro processo e per sospendere processi. In pratica ciò richiede SeDebugPrivilege o capacità equivalenti per aprire e manipolare handle e thread di altri processi. Senza privilegi elevati l’attacco non riesce. - Invoker: WerFaultSecure + MiniDumpWriteDump.
WerFaultSecure.exe è parte del Windows Error Reporting e, in alcune configurazioni, è in grado di generare dump per processi ad alta integrità o protetti perché viene eseguito come Protected Process Light (PPL). La routine tipicamente utilizzata è MiniDumpWriteDump (esportata da dbghelp.dll), che sospende tutti i thread del processo target per catturare uno snapshot coerente della memoria e poi riprende l’esecuzione. Normalmente la sospensione è temporanea (frazione di secondo). - Creazione della race / mantenere il target sospeso.
L’elemento chiave è: durante la creazione del dump i thread del target sono sospesi; la PoC sospende il dumper (WerFaultSecure) dopo che ha sospeso il target ma prima che possa riprenderlo. Con WerFaultSecure sospeso, non può completare l’operazione di ripristino: il processo target rimane bloccato in stato di Suspended indefinitamente fino a ripresa manuale, riavvio o kill. La PoC implementa logiche di monitoraggio e timing per ottenere questo stato in modo affidabile. - Risultati e limitazioni pratiche.
- Il processo target non viene terminato: è semplicemente fermo.
- La ripresa riporta il comportamento normale — un riavvio o la riattivazione del processo lo riporta operativo.
- È una tecnica situazionale: richiede privilegi e orchestrazione precisa, quindi è più un primitivo di elusione che un vettore di attacco efficace su larga scala.
Artefatti osservabili e opportunità di detection
Dal momento che la tecnica sfrutta componenti di sistema firmati, la strategia difensiva si basa su comportamento e correlazione di telemetria più che su firme statiche. Artefatti utili sono:
- Command line di WerFaultSecure e tempistiche di invocazione. Invocazioni legittime del WER sono tipicamente correlate a crash. Esecuzioni di WerFaultSecure.exe con argomenti espliciti (/pid, /encfile, ecc.) contro PID di agenti, fuori da un contesto di crash, sono sospette.
- Processi in stato Suspended. API e strumenti riportano lo stato dei thread/processi. Un agente di sicurezza che resta sospeso oltre la finestra temporale attesa per un dump è un indicatore.
- Eventi di accesso al processo. Chiamate che aprono handle con PROCESS_SUSPEND_RESUME o uso di SeDebugPrivilege da binari non usuali sono segnali rilevanti. Sysmon (Event ID di ProcessAccess) e ProcessCreate aiutano a ricostruire la catena: dumper lanciato → accesso/sospensione del dumper.
- Lacune di telemetria / perdita del “heartbeat”. Se la telemetria dell’agente cessa contemporaneamente alla comparsa del dumper, la correlazione temporale è un’evidenza ad alta fedeltà.
Questi segnali, opportunamente correlati, consentono di distinguere attività legittime da abusi.
Mitigazioni concrete
Di seguito alcune raccomandazioni specifiche e implementabili nella maggior parte degli ambienti enterprise; sono intenzionalmente focalizzate per ridurre i falsi positivi e per consentire azioni automatiche limitate.
- Regola Sysmon: alert su WerFaultSecure con argomenti di dump
- Monitorare Image = C:\Windows\System32\WerFaultSecure.exe con CommandLine che corrisponde a (?i)/pid\s+\d+|/encfile. Escludere processi parent standard (svchost.exe, services.exe) secondo baseline locale. Al match, generare allarme per indagine.
- Rilevamento di processi Suspended a lunga durata e rimedio automatico
- Implementare uno script/azione dell’agent: ogni minuto enumerare i PID degli agent protetti; se lo stato thread/process riportato indica Suspended per >30 secondi senza crash registrato, lanciare un tentativo di restart controllato del servizio o un job di remediation che logga evento, invia allarme e riavvia l’agente. Questo riduce la finestra sfruttabile.
- Limitare e monitorare SeDebugPrivilege
- Tramite GPO, PAM o controlli LAPS, assicurarsi che SeDebugPrivilege sia concesso solo ad account amministrativi noti e a servizi attesi. Loggare e allertare su acquisizioni di questo privilegio da parte di eseguibili anomali.
- Hardening del percorso di invocazione di WER (WDAC/AppLocker)
- Applicare policy WDAC o una regola AppLocker che limiti quali binari o contesti possono lanciare WerFaultSecure.exe con argomenti non standard. Se WDAC è impraticabile, definire una regola AppLocker che blocchi esecuzioni non autorizzate del dumper.
- Regola di correlazione SIEM ad alta fedeltà
- Sequenza da implementare: WerFaultSecure ProcessCreate → agente diventa Suspended → agente manca il heartbeat entro 5–15 secondi = escalation SOC. Questa correlazione riduce falsi positivi.
Indicatori di compromissione
| 2054a0866411f22a98c3fedc200d6947facdd6046a5e51ec9109380ef0cf2dd1 |
| d989ebd417e6fae60a544e43bfc0ee63f5d9352ce0059b95ed4e7e18efbc5d0b |
| 8819d5a64d7b95314630ed54156240c855e570b94bc01a88357e626615221858 |
| 1fa74c9be827171bfff81757130dbd1f1f79436199b4c4955410cf241e2b7a88 |
| 222649815d204ce19f652b3b57c81ddda3182f7a2851b9e4166d9160b2954d13 |
| 69e9b4ef471fb1ed719a44fe0a4e5aff5b341ee5a81d22cb3c57020d76a83f04 |
| e2b2dd0984e52112965392471f6a09020eb8380aa53d48d2fb4dd3aaa7edae9b |
Note finali
EDR-Freeze è una dimostrazione mirata che riutilizza un comportamento legittimo del sistema operativo in modo non previsto. Non è un rootkit kernel né un payload persistente, ma evidenzia come la fiducia nei componenti di sistema possa essere sfruttata in scenari con privilegi elevati. Con telemetria adeguata e regole comportamentali mirate, tecniche come questa possono essere rilevate e mitigate.






